3 ms·

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

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.

abadpoli 3y ago
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.
- electroly 3y ago
  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.
  - abadpoli 3y ago
    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.
    - electroly 3y ago
      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.
- jasode 3y ago
  >The fact that AWS does not consider the ID a secret means that your company never should either. 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: https://news.ycombinator.com/item?id=29209312 https://news.ycombinator.com/item?id=29209312
- sroussey 3y ago
  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.
- kube-system 3y ago
  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.
- deleted 3y ago
  [deleted]

abadpoli 3y ago

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.

electroly 3y ago
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.
- abadpoli 3y ago
  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.
  - electroly 3y ago
    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.
jasode 3y ago
>The fact that AWS does not consider the ID a secret means that your company never should either. 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: https://news.ycombinator.com/item?id=29209312 https://news.ycombinator.com/item?id=29209312
sroussey 3y ago
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.
kube-system 3y ago
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.
deleted 3y ago
[deleted]