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.
The fact that AWS does not treat the ID as secret means you have no guarantees that anyone within AWS cannot see or find your ID. You also have no guarantee that AWS at some point won’t expose your ID to the world and break your entire security model, because AWS doesn’t think it’s secret. If you do, you’re basing your security off of false assumptions.
Stated another way: you can unintentionally make your account ID sensitive if you're not careful. You have to be careful.
> 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 AWS does not
The point here is that if you want to have good security, you _cannot_ “care” about this if your service provider does not also care about it. If you “care” about your ID being public, but your provider does not, then if you want to have good security you must either find a way to not care, or find another provider.
You and gp are talking past each other.
Your focus is on Account ID being public should not be a security vulnerability.
Instead, the gp's focus is on metadata leakage of identity.
Same type of conversation that differentiates concepts of "public key" vs "published key" of SSH keys:
It narrows all the possible account IDs to one.
Is that ID already compromised? Can you gain access through someone else that does the work for you?
You can cross reference with other systems you have compromised. Is that account ID in their system? What access does that give you?
Etc, etc. It is not a secret, but it absolutely is valuable.
For example, if you considered it a secret (even though it is not), you might not choose to use third parties that require it, and that can improve your security posture.
You might have a 100% secure system, but you don't want your competitor to know exactly what you are doing. You might also not consider their knowledge of what you're doing to be a vulnerability, nor think that you should spend many resources on preventing them from knowing, you just don't want to make it easy for them.
Cryptography is very black-and-white. Business operational intelligence is not.
https://docs.aws.amazon.com/accounts/latest/reference/manage...
> While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.
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.
That was my point. The fact that some organizations consider AWS account IDs sensitive is independent of whether they rely on it being sensitive or not.
I might have taken all precautions against an assassin attack, yet I won't make the assassin's job easier by announcing my PII to them. The fact that I won't announce my PII says nothing about whether I took the security precautions.
There’s a difference between “making it easier for an attacker” and using it as a security control, even if it’s not the only security control. The point is that even if you don’t go around wearing a shirt with your address on it, that should never factor in to your designs for security. It should never be considered a security control, even a “defense in depth” one.
In fact, your threat model should ideally ask the question “assume someone does walk around with a shirt with my address on it, will I still be safe?” That doesn’t mean you’re actually going to go do it, but if the answer is yes, that’s how you know you’ve done your job.
Then I don't understand why you object so strongly to the tshirt example unless you're deliberately talking past the person that made it.
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).
Any time a topic like this comes up, there are people on this forum that try to apply the "security by obscurity does not work" principle to every security topic under the sun, when in reality, that principle really only applies to the world of cryptography. In meat space, where humans operate on plaintext, keeping a secret is a very valid approach to some topics. This is why things like NDAs exist.
There is a lot of data that exists in a space somewhere between "100% secret" and "100% public". This is one of those situations, for many organizations.
> This is one of those situations, for many organizations.
And those organizations are wrong.
> by pretending it’s secret
No, nobody needs to pretend it is secret. You're missing my above point. There is not a dichotomy between secret and public. It is possible for something to be neither secret nor public.
* Security through obscurity provides secondary security only, so it doesn't add to defense-in-depth significantly. If it can be added, then it is slightly safer to prefer to do so. Elimination of unprivileged enumeration and internal primary key predictability are relatively more important to reduce the attack surface.