While I agree, the way you wrote this might mislead people into thinking that you meant you can treat your account ID as non-secret because AWS does. That doesn't directly follow; 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. Rather, 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 you'd prefer to keep private. Correlated ownership of buckets (e.g. different clients of the same design firm) in particular is something AWS doesn't care about, but you might. If you don't want people to know that the buckets have the same owner, better split it up into separate accounts to preserve the non-secretness of the account ID.
No, this is wrong. The fact that AWS does not consider the ID a secret means that your company never should either. If your company “cares” about its ID being secret, then your company is designing its systems in an insecure way.
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.
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 different clients, you're leaking the information that they are your customers. Better split it up into separate accounts to preserve the non-secretness of the account ID--another direct quote from my original post.
Stated another way: you can unintentionally make your account ID sensitive if you're not careful. You have to be careful.
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 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.
Correlation of bucket ownership isn't a security issue at all. I never used that word in my posts, and the author of this article also never suggested that it was. That's the point--there are other considerations that AWS does not care about, but your business does. Your cloud deployment needs to be designed such that the account IDs do not leak information that your business doesn't want to be revealed. You don't get the non-secretness for "free"--you have to think about it and be careful on how you isolate things into accounts. As far as I can tell, we agree on all of this and have just suffered some misunderstanding in this thread.
No, this is wrong. Just because it is not a secret does not mean that is disclosure is not valuable. You need that information to compromise it.
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.
No, operational security might still a valid concern even where there are no issues with digital security.
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.
AWS doesn't consider them sensitive, but some organizations do. My feeling is that I would rather avoid leaking any info about my AWS environments. Just because AWS doesn't think they can be dangerous doesn't mean someone else won't find a way.
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?
> While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.
If you knew that there was an assassin out there trying to find you and cause you harm, would you consider “I don’t wear a t-shirt with my address on it” to be any form of protection against that assassin?
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.
> 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”.
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.
If an organization considers it sensitive, that implies they’re putting some level of reliance on it being so. Otherwise there would be no point in considering it sensitive.
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.
You’re still misunderstanding. I’m not saying you should go “paint a target” on yourself, I’m saying you should assume _someone else is_ going to paint a target on you, and defend yourself accordingly, rather than acting like the lack of a target protects you in any way.
If you place any sort of security assumptions on AWS account IDs into your threat model, you're effectively directly introducing a security vulnerability. If you're not then why include it into your security threat model to begin with? I believe that is their point.
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).
This is a false dichotomy. There is a deep chasm between "publish everything", and "this is a secret", called operational security.
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.
How is it possible for a user of AWS to keep the account ID secret if Amazon doesn't even consider it secret? If Amazon leaked your account ID they could point to their docs and say the account ID was never meant to be a secret, sensitive, or confidential.
You can walk over to the user's desk and ask them not to share it. Whether or not Amazon leaks it is unrelated to my employees' ability to follow instructions.
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.
You’re wasting your employees time by asking them to keep it secret, when you gain absolutely no benefit from keeping it secret (and in fact are introducing an easy failure point by pretending it’s secret) and you have no guarantees that others are keeping it secret.
> This is one of those situations, for many organizations.
Many organizations just have a blanket policy that you shouldn't be exposing data about an organization's infrastructure unless you need to do it. This is a good policy.
> 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.
Well, as a very relevant example, if you tell others what your AWS account ID is, they can figure out if you own any particular bucket. The metadata association between the content of that bucket and the owner might give away information that the contents of the bucket doesn't indicate on its own. It also might not be a technical vulnerability, but that association itself could imply some proprietary business information. Or it could give clues to any would-be attacker as to other resources to target. In business, there are lots of types of information that are not secret, but are also not public.
If you assume it is a secret, you might start to use it as an access key, or similar things. That's where the error is. You should assume it is public (but avoid publishing it yourself of course, that's defense in depth)
I think making the assumption that account IDs won’t leak is the problem. It’s safer to assume that someone out there already has a directory of account IDs to buckets and that your efforts are better expended on other things, like actual secrets.
I guess anything that looks like random letters/numbers is going to be considered a secret to some people. If it wasn't meant to be secret, it would be human readable. Or some such nonsense.
* 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.
They’re not a secret, in fact it’s what you use to share the identity of one account with another, possibly third party’s account. It’s a secret in the way your personal email address is. You may not advertise it on 4chan, but you definitely share it to limited audiences. Once you’ve shared it it’s no longer an actual secret. Indeed, as has been noted, aws itself doesn’t treat your account id as a secret and freely shares it within aws, logs it in plain text, uses it for operations with human operators, internal reporting, etc. It’s an identifier, it’s discoverable, shareable, and leaks all over the place.
This is not the stuff secrets are made of.
Trying to eek some sort of security story out of hiding account ids plays right into security through obscurity. As it’s not treated as a secret the most you’re doing is obscuring the attack surface of your infrastructure. IAM doesn’t allow anyone to use the knowledge of your account ID to grant any privilege not specifically granted within the account itself via two way grants. Holes in your IAM policies aren’t protected by hiding the account ID, they’re protected by closing the holes.
Yes, but I do use random email addresses (that look like passwords) to stop correlation, concerted credential stuffing (that might lock me out for a time), etc. And if it pops up in a compromised server no one will know that email address is mine.
And aws also offers ideas like external IDs and similar concepts to do something like this.
But you might notice that even aws services advertise their own account ids. They’re not secrets and treating them as such doesn’t help you improve security.
AWS account IDs aren’t secret, but the identity of who owns particular S3 bucket names is meant to be.
If you get an email apparently from AWS that correctly names an S3 bucket and the associated account ID, are you more likely to take it seriously than an email that just names a bucket?
Not to mention it also means you can establish relationships between buckets by finding common ownership.
No, the account ID isn’t secret but I don’t think we should be dismissive of this new information either. It’s still important metadata to factor into decision making.
More generally, this opens up all sorts of threat models for espionage and alternative data. A private bucket called project-foobar-logs-staging might have its existence known in an index but never have been known to be associated with Baz Corp's publicly-known image buckets - but with this disclosure, a database will become available making that association possible. And it will be possible to monitor if and when project-foobar-logs-prod gets provisioned. Not to mention that state-level actors would love to see an enumerable list of projects their rivals are working on, and if any of them happen to have been secured only by obscurity in the past.
Everyone here throwing down the “technically not a secret” card but I don’t think that was your point. I guess “sensitive, but not secret” is the right way to say it. They’re obviously not secret like credentials, but it’s a damn good piece of info for an attacker to hold against you, because, like you said, it’s impossible to rotate, but is tangentially related to every single part of your AWS infrastructure (per-account of course).
I guess I disagree with the AWS documentation then. It should be treated as a sensitive piece of information that should not be exposed to the public. It’s not going to bring you down if it’s leaked, but it could be used along with other leaked info over years in more sophisticated attacks. Why risk it is more the point.
In fact, when delegating IAM access (where security is top of mind), account IDs are shared liberally.
Account IDs are as secret as phone numbers. That bit of info could be tangentially useful to an attack, but really shouldn't be assumed to be secret in any meaningful way.
But there’s a reason people advise against security by obscurity: the obscurity can go away at any time and once it does it’s unrecoverable.
So sure, maybe pat yourself on the back today that on top of your other measures, no one outside your org and AWS knows your Account ID. But if it gets out at some point, those other measures should be foiling your pentesters on their own. In fact, to better test that this is the case, you should probably give the pentesters your account ID so you can be informed regarding your security in this scenario.
Unfortunately, until humans have crypto modules installed in their brains, we will have to rely on some form of "security by obscurity" that many colloquially call "operational security".
Yes, there are types of data and metadata about your company's infrastructure that can be used against you. But no, you shouldn't hand it to attackers on a silver platter.
> In fact, to better test that this is the case, you should probably give the pentesters your account ID so you can be informed regarding your security in this scenario.
That depends on the scope of the test. Many organizations will do both (and others) to test different layers of security. Remote software exploits are something that many people on this forum are concerned about, but that is hardly the be-all-end-all of security for an organization. There's a lot of security topics entirely outside the scope of computer systems to be cognisant about here.
When obscurity is the only option, like opting not to expose AWS account ID, why not do it? Don’t think this should be conflated with replacing proper security with obscurity, which is obviously wrong. The less you expose about your operation, the better. Not exposing details of your infrastructure to the public is another commonly suggested best practice that is obscurity, not security, that nobody challenges. For example, cleaning up common default response headers for things like cloud front.
You can't keep it secret because Amazon doesn't keep it secret.
So if Amazon doesn't keep the account ID a secret how can you as a user of Amazon be expected to keep your account ID secret? There's no way for you to stop Amazon from exposing it.
You as a user of Amazon can do whatever you want though, including being careful about which pieces of information you elect to expose publicly. If it’s up to you, why choose to expose it, when you can choose NOT to? Just because this reverse search of bucket to account id exists doesn’t mean you should begin to expose your account id on your own.
You can't choose NOT to expose it because you can't stop Amazon from exposing it.
Amazon says it's not secret, so it's not secret. They make no attempts or guarantees to keep it secret so there's always the threat that Amazon themselves can expose it on your behalf. You can't stop that no matter how wrong you think it is.
Doesn't change the fact that security by obscurity is a layer of security. It's not a good layer, it's not one you should depend on, but it is a layer that causes problems for attackers.
