Hacker News Reader

Comment by INTPenis | Hacker News Reader

It's valuable info to any pentester. Security by obscurity is still one layer of security.

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.

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.

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.

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.

Reply on news.ycombinator.com