41–50 of 227 posts
> The ability to apply a wildcard match on the s3:ResourceAccount condition key That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.
Can we go further, and find the email associated with an account ID?
id is static while email can be changed.
Earlier quoted context omitted.
AWS Account IDs are not secret and don’t need to be. AWS doesn’t design anything that assumes your account ID is secret, and you shouldn’t either.
I've gotten in long arguments with senior IT people who refuse to believe this even when they talk to AWS directly about it.
let's say if apple uses s3, they need to create bucket name "apple.com", and then we can find what aws account which apple is using.
Earlier quoted context omitted.
It’s not defense in depth to build your security model off of false assumptions, it’s just bad security.
I don't understand your reasoning. Neither my name nor where I live nor my phone number nor my license plate are secrets. Yet I don't go around wearing a t-shirt with my personally identifying information printed on it. What am I missing?
If you want protection against that, you need to focus on better home security, hiring bodyguards, going to the police etc, and you’re better off assuming that the assassin will find your address regardless of whether or not you wear a t-shirt with it printed on.
Put another way: there’s a difference between “I don’t do this thing” and “I rely on not doing this thing for my safety”. The second one makes a lot more assumptions than the first one does, and those assumptions can lead to problems if they are false assumptions.
Earlier quoted context omitted.
It’s not defense in depth to build your security model off of false assumptions, it’s just bad security.
I don't understand your reasoning. Neither my name nor where I live nor my phone number nor my license plate are secrets. Yet I don't go around wearing a t-shirt with my personally identifying information printed on it. What am I missing?
Since AWS does not, and has never, treated that information as secret, then there is absolutely no reason to consider it sensitive because there is no security guarantees with how AWS handles those IDs (as this article demonstrates).
Thus, either you're including them into your threat model as sensitive and thus immediately opening up yourself to vulnerabilities (bad security), or you're not including them at all (and thus not treating them as sensitive/secret/whatever). The argument the parent had (and that I agree with) is that you should do the latter unless AWS provides a means to work with those IDs securely (it won't because they're not secrets).
For those interested, we put the code online here: https://github.com/tracebit-com/find-s3-account
Earlier quoted context omitted.
You've said "this is wrong" and then repeated exactly my point back to me. I suspect some misunderstanding has occurred here. We are agreeing on this--you need to follow AWS's lead and design your cloud deployment such that the account ID doesn't leak anything interesting about your business. That's a direct quote from my original post. I further gave an example--if you're a design firm using a single account for dif…
I think we agree, but either your meaning or your words are giving me pause. > you can treat your account ID as non-secret because AWS does. That doesn't directly follow; It does follow, and not only that, but not only “can” you treat them as non-secret, you _must_ treat them as non-secret. > the difference between AWS's point of view and your company's point of view means there are things you might care about that A…