11 ms·

>Randomise your bucket names! There is no need to use company-backup.s3.amazonaws.com This is really poor advice. It offers no real benefit, especially since a

>Randomise your bucket names! There is no need to use company-backup.s3.amazonaws.com This is really poor advice. It offers no real benefit, especially since any asset you access will betray your bucket name because it's part of the DNS resolution. Bucket names are emphatically public as much as a DNS name is public.

jcims 9y ago
I wouldn't call it poor advice. It isn't a control, more security by obscurity, but it doesn't exactly hurt anything either. I saw a situation recently where a bucket was accidentally opened to the world, but the name was a UUID and in the entire history of the bucket no request was logged other than from the intended clients.
- IanCal 9y ago
  > but it doesn't exactly hurt anything either. It hurts me if I'm trying to remember the bucket I'm after. Is fc20d856-2a7e-41ab-b072-9bb9a68c6bda production or 193565ac-9121-4071-8aeb-62f3111c4c97 or is that the dev setup or the staging data for the other service or... To me the big question here is why these names have to be global. Why can't I have a UUID externally but a name and an account internally? Honest question, I assume there may be a significant issue as smarter people than me decided not to do it that way.
  - deleted 9y ago
    [deleted]
  - TheDong 9y ago
    I've heard many aws employees lament the global namespace of s3 bucket names. They think it's a mistake too. Though if they weren't global, they'd probably be "name.accountid.s3...." which isn't really obscure either since aws account ids are semi-public.
- alpha_squared 9y ago
  > in the entire history of the bucket no request was logged other than from the intended clients This sounds sort of like dumb luck. It just means no one was looking for it, that doesn't mean it's secure. This all reminds of me of the xkcd about making passwords that are easy for computers to guess and hard for people to remember[0]. Your security on buckets should be the bucket policy/permissions themselves, not the arbitrary naming of them. Security by obscurity is rarely secure and more about the illusion of security. [0] https://xkcd.com/936/ https://xkcd.com/936/
  - jcims 9y ago
    I couldn't agree more with your second point, but risk is usually considered the product of likelihood and impact. If I name my bucket 'bestbuy' vs '4fc6-43b0-bc19-75fe07e06133', the likelihood that some random is going to find my bucket increases dramatically.
    - onion2k 9y ago
      The chance of it being found by someone guessing the name would increase dramatically. The chance of it being found by someone running a script that searches for buckets using DNS logs, code searches, etc would be the same. Hackers don't often try to guess things. They run scripts. That's why it doesn't matter what you call the bucket.
vhold 9y ago
I can think of one advantage.. it makes it difficult for somebody to attack you with a typo attack. If all your buckets having a consistent naming scheme that is very strict, then somebody else could make a bucket very similar to one of yours where a typo would be likely and your data starts going to them.
outworlder 9y ago
True. It can also create more problems. If you name something like companyname-production vs companyname-qa, you pretty much know right off the bat which environment you are about to mess up. Not so with random names or UUIDs. This is also security by obscurity. If all one needs to know is the bucket name, you have already lost. EDIT: As an exception to this, I randomize a portion of the bucket name when it is created by automation. But this is solely to avoid name clashes across separate clusters. The prefix will still be the same.
- noncoml 9y ago
  > This is also security by obscurity. I see this being claimed a lot, but isn’t all security by obscurity at the end of the day? A simplistic example, compare (A) with (B). A) I run telnet with no password on a random port. The changes for an attacker to guess my password are 1/65k. B) I run telnet in port 25 with password being a random number from 1 to 65k. How do A and B differ in security?
  - eranation 9y ago
    A) brute force takes 65K max attempts B) unless you know the password MUST be a number and MUST be between 1 and 65K (which is a terrible password requirement, e.g. a password of max length 65000 using only digits 0-9 is as good as no password), you need to brute force the entire known character space up to some finite number. The sun will die first.
    - noncoml 9y ago
      You are missing the point of the example.
      - eranation 9y ago
        I actually somewhat agree with your point, your example is simply not realistic. Your point is correct because people are using the term security by obscurity wrong. Security by obscurity means that you rely on the secret implementation of your algorithm. Our best encryption algorithms are public so they can be poked and peer reviewed. You are right in the fact that through enough obscurity of the key, you attain security as it's non feasible statistically to brute force. If you have a public & unlisted endpoint that looks like https://example.com/VERYLONGANDRANDOMKEY https://example.com/VERYLONGANDRANDOMKEY You might argue it's as good as a request to https://example.com https://example.com with an Authorization header containing this key for example. (Well, not exactly the same, as most access logs will include the first and not the second, but for the sake of the argument) p.s. I don't agree for example that VERYLONGANDRANDOMKEY.example.com is the same, as if I'm not mistaken, if you just scan the entire IP range, then try to do a reverse DNS lookup, you'll end up finding it anyway.

jcims 9y ago

I wouldn't call it poor advice. It isn't a control, more security by obscurity, but it doesn't exactly hurt anything either. I saw a situation recently where a bucket was accidentally opened to the world, but the name was a UUID and in the entire history of the bucket no request was logged other than from the intended clients.

IanCal 9y ago
> but it doesn't exactly hurt anything either. It hurts me if I'm trying to remember the bucket I'm after. Is fc20d856-2a7e-41ab-b072-9bb9a68c6bda production or 193565ac-9121-4071-8aeb-62f3111c4c97 or is that the dev setup or the staging data for the other service or... To me the big question here is why these names have to be global. Why can't I have a UUID externally but a name and an account internally? Honest question, I assume there may be a significant issue as smarter people than me decided not to do it that way.
- deleted 9y ago
  [deleted]
- TheDong 9y ago
  I've heard many aws employees lament the global namespace of s3 bucket names. They think it's a mistake too. Though if they weren't global, they'd probably be "name.accountid.s3...." which isn't really obscure either since aws account ids are semi-public.
alpha_squared 9y ago
> in the entire history of the bucket no request was logged other than from the intended clients This sounds sort of like dumb luck. It just means no one was looking for it, that doesn't mean it's secure. This all reminds of me of the xkcd about making passwords that are easy for computers to guess and hard for people to remember[0]. Your security on buckets should be the bucket policy/permissions themselves, not the arbitrary naming of them. Security by obscurity is rarely secure and more about the illusion of security. [0] https://xkcd.com/936/ https://xkcd.com/936/
- jcims 9y ago
  I couldn't agree more with your second point, but risk is usually considered the product of likelihood and impact. If I name my bucket 'bestbuy' vs '4fc6-43b0-bc19-75fe07e06133', the likelihood that some random is going to find my bucket increases dramatically.
  - onion2k 9y ago
    The chance of it being found by someone guessing the name would increase dramatically. The chance of it being found by someone running a script that searches for buckets using DNS logs, code searches, etc would be the same. Hackers don't often try to guess things. They run scripts. That's why it doesn't matter what you call the bucket.

vhold 9y ago

I can think of one advantage.. it makes it difficult for somebody to attack you with a typo attack. If all your buckets having a consistent naming scheme that is very strict, then somebody else could make a bucket very similar to one of yours where a typo would be likely and your data starts going to them.

outworlder 9y ago

True. It can also create more problems. If you name something like companyname-production vs companyname-qa, you pretty much know right off the bat which environment you are about to mess up. Not so with random names or UUIDs. This is also security by obscurity. If all one needs to know is the bucket name, you have already lost. EDIT: As an exception to this, I randomize a portion of the bucket name when it is created by automation. But this is solely to avoid name clashes across separate clusters. The prefix will still be the same.

noncoml 9y ago
> This is also security by obscurity. I see this being claimed a lot, but isn’t all security by obscurity at the end of the day? A simplistic example, compare (A) with (B). A) I run telnet with no password on a random port. The changes for an attacker to guess my password are 1/65k. B) I run telnet in port 25 with password being a random number from 1 to 65k. How do A and B differ in security?
- eranation 9y ago
  A) brute force takes 65K max attempts B) unless you know the password MUST be a number and MUST be between 1 and 65K (which is a terrible password requirement, e.g. a password of max length 65000 using only digits 0-9 is as good as no password), you need to brute force the entire known character space up to some finite number. The sun will die first.
  - noncoml 9y ago
    You are missing the point of the example.
    - eranation 9y ago
      I actually somewhat agree with your point, your example is simply not realistic. Your point is correct because people are using the term security by obscurity wrong. Security by obscurity means that you rely on the secret implementation of your algorithm. Our best encryption algorithms are public so they can be poked and peer reviewed. You are right in the fact that through enough obscurity of the key, you attain security as it's non feasible statistically to brute force. If you have a public & unlisted endpoint that looks like https://example.com/VERYLONGANDRANDOMKEY https://example.com/VERYLONGANDRANDOMKEY You might argue it's as good as a request to https://example.com https://example.com with an Authorization header containing this key for example. (Well, not exactly the same, as most access logs will include the first and not the second, but for the sake of the argument) p.s. I don't agree for example that VERYLONGANDRANDOMKEY.example.com is the same, as if I'm not mistaken, if you just scan the entire IP range, then try to do a reverse DNS lookup, you'll end up finding it anyway.