161–170 of 227 posts
ITT lots of debate on whether AWS Account IDs are sensitive or not. To chime in my 2c; we've had this debate in multiple orgs with different security teams and the outcome has always been the same; they're not and it's counterproductive to your security posture to treat it as privileged information. Humans have a nasty habit of placing trust in people who have access to privileged information. "Hi, this is Tom from A…
Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f... These key IDs are included in the URL for pre-signed links to S3, so there's a good chance you've already been publishing your account ID.
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not ) Anything non-"security by obscurity" does not depend on you understanding something or not - it wi…
There is a way to view bananas at
/bananas/:bananaUUID
unsecured endpoint.
I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.
Earlier quoted context omitted.
Email providers have rate limits against specific user logins, IAM not.
How do you know that?
In contrast, every half-decent IdP will lock an account automatically after anything from 3-10 wrong attempts.
Earlier quoted context omitted.
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not ) Anything non-"security by obscurity" does not depend on you understanding something or not - it wi…
To me security by obscurity is limited to things like this: There is a way to view bananas at /bananas/:bananaUUID unsecured endpoint. I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.
Security through obscurity means substituting security for a flawed algorithm that is usually trivial to exploit if the attacker is made aware of the algorithm. Think things like no authentication and ROT13ing and Base64ing clientside. If the method leaks or is discovered, the whole system is broken.
You just told me your algorithm and I cannot get to your banana because the UUID key space is insanely large. So that's not security to obscurity.
Earlier quoted context omitted.
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not ) Anything non-"security by obscurity" does not depend on you understanding something or not - it wi…
To me security by obscurity is limited to things like this: There is a way to view bananas at /bananas/:bananaUUID unsecured endpoint. I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.
Earlier quoted context omitted.
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not ) Anything non-"security by obscurity" does not depend on you understanding something or not - it wi…
To me security by obscurity is limited to things like this: There is a way to view bananas at /bananas/:bananaUUID unsecured endpoint. I don’t want people to get all my banana data, but as long as there isn’t an easy way to list banana uuids, that endpoint is basically effective security by obscurity.
Hopefully you're using version 4 UUIDs. Those set aside 6 bits to encode UUID details, keeping 122 bits of entropy. Since every banana needs its own identifier, subtract the number of bits needed to uniquely represent bananas. What's left will unavoidably be less guess-resistant than client secrets. Other versions of UUID use many more bits for low-entropy purposes.
Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f... These key IDs are included in the URL for pre-signed links to S3, so there's a good chance you've already been publishing your account ID.
Quite a few people in this thread assume that the AWS key id is part of a "security by obscurity" "protection in depth". This will probably be downvoted, but if you read this anyway: this is a good example of why "security by obscurity" is not a good defense. You will overlook something (a determined attacker will not ) Anything non-"security by obscurity" does not depend on you understanding something or not - it wi…
Related: AWS key IDs (not the secret key part) include your account ID within them, bitshifted by one position: https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f... These key IDs are included in the URL for pre-signed links to S3, so there's a good chance you've already been publishing your account ID.
While I wouldn't publicly hand out my account IDs as a general practice, I think you have to expect that some of them will be disclosed at some point. As more third party vendors and SaaS platforms move away from IAM users and access keys to using role assumption as the preferred method of integration (as they should!), the account ID of at least the account you use as their integration point is now known by another…
This is what I’m curious to learn. What can an attacker do with an AWS account ID? How is that any different from knowing someone’s email address?