Comment by matt_wulfeck
8 years ago
>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.
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.
> 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?
> I see this being claimed a lot, but isn’t all security by obscurity at the end of the day?
I Do Not Think It Means What You Think It Means [1].
To elaborate, the concept is not formal/mathematical, it's a design concept. You can distinguish between a security implementation that explicitly depends on a secret key or password, and an implementation that implicitly relies upon secret implementation details for its security. The latter is not intentionally designed as a carefully-controlled secret, and therefore much easier to accidentally leak.
[1] https://en.wikipedia.org/wiki/Security_through_obscurity
2 replies →
Whilst they don't in your example, choosing a password between 1 and 65K is a very bad decision to begin with (assuming the attack knows this ... if they don't the password search space is far larger than the port search space)
In general A does not improve your security 65K times since a single attempt will tell if there is telnet on the port or not, whereas with B all you know if you got the wrong password.
Now if you ran a dummy telnet that always can slow 'wrong password' responses on the other (65K-1) ports that would potentially increase the security 65K times, but still isn't really a meaningful thing to do.
3 replies →
A is a realistic case of security by obscurity - there's a sizable amount of people who believe that to be secure.
B is in my opinion much less realistic: very few people believe a password two bytes long (or better, with two bytes of entropy) to be secure. Even a trivial password like "TelnetSucks" scores 31 bits of entropy with https://apps.cygnius.net/passtest/.
1 reply →
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.
8 replies →
At the most abstract level, security is RISK management which is related to SECRETS management. So, on some level it is true that security is equivalent to obscurity. But, that's like saying that cars are molecules. It is true, but it is not a useful statement.
There are two operative principles of security that you should research. 1) Defense in depth, where there is more than one layer of security that must be pierced. 2) Assume that the attacker knows absolutely everything about your system, design, ports, and so on - except for the key material.
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.
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.
> 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.
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.
> 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/
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.
1 reply →