Hacker News Reader

Comment by busymom0 | Hacker News Reader

Slightly related - CloudFlare account_id and zone_id are safe to be public

https://github.com/cloudflare/cloudflare-docs/issues/474

https://community.cloudflare.com/t/api-zone-id/355566

> The Zone ID and Account ID are not sensitive. Sensitive data like account API Key, Secrets etc. can all be revoked, rotated or changed. See the comment 36 below on the Wrangler repo: as per our security team, it’s completely Fine to have your zone_id and account_id public, the Global API key and associated email address should be kept secret.

View on HN

AWS account ID is also safe to be public.

That said, one thing I could think of that this could be used for is correlation. If you’re running multiple S3 sites from the same AWS account, people would be able to see that they’re hosted by the same account. Whether or not this matters depends on your threat model.

Exactly - this isn't going to open the door for someone but could add a ton of value to enumeration.

As we are very canary focused, we also think it's interesting to consider the implications of the recent research from Truffle Security w.r.t canary tokens (https://trufflesecurity.com/blog/canaries).

> AWS account ID is also safe to be public.

Not necessarily. An AWS account ID + the knowledge of a role name that by mistake has the "allow role assumption" allowlist too wide (say "*") is now enough to take over the account.

One might of course say "well then don't do that", but of course the more complex a system like IAM is the easier it is for unexperienced people to open the floodgates.

Well sure, but your account email isn't safe to be public if your password is "password".

Email providers have rate limits against specific user logins, IAM not.

How do you know that?

That's easy to find out: change the API credentials of a user, but forget to update the service. Notice only a few days later that you forgot the change, but you also never got any notification "something" is going wrong.

In contrast, every half-decent IdP will lock an account automatically after anything from 3-10 wrong attempts.

Turning what you said around, you're arguing you might want to keep an account ID secret for "security by obscurity" reasons. In my mind, even in a multi-layer security solution, even then the account ID should be considered as a public string whose knowledge (along with other bits like what misconfigurations it has) provides no additional vector of attack, because of defense in depth.

Oh, there are other things... like a compromised chrome extension that only looks for your accountID being used and sends back credentials.

Knowing an accountId tells you where to focus your efforts. You got through one hoop (of many).

For CF accounts, I use the gmail `+ feature` to make a totally unique email address that cannot be easily guessed. Not perfect, but adds another layer of abstraction.

If I remember right, the pre-signed url generated for R2 uploads include the account ID in it.

Reply on news.ycombinator.com