I'm uploading files on S3, where the filename is a UUID. All files uploaded are publicly read/write, however these files are considered private to users.
Is it possible for someone to guess a UUID, or randomly try a bunch of combinations to access some of these files?
Is there a better way to secure S3 files?
UUIDs generated following RFC 4122 come in several “versions”; in a UUID of the form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (in hexadecimal), then:
If the UUID doesn't meet any of these constraints, it wasn't generated according to RFC 4122. But even if the constraints are met, this doesn't guarantee than the RFC was followed, or that the random generator was a good one.
I don't know what S3 does for UUIDs.
Even if the UUIDs are properly random, which would make the URL unguessable, protecting access to a resource with only a URL is a bad idea. URLs tend to leak in many ways: shared in emails or chat, lying around in browser histories and bookmark lists, accidentally copied around, or worse, left as a link in a page that the author meant to keep private but that had no authentication and got indexed by Google.
If you want to protect access to a resource on the web, do not rely on the URL being kept secret. Add an authentication mechanism. Even plain old password authentication is a huge improvement on an unguessable URL — browsers and even people know that they shouldn't be sharing passwords around, whereas URLs are normally public knowledge.
The 100% correct solution, obviously, would be not to make files publicly readable and writable. That's out of your control here, but it is also not strictly necessary.
The server is set up in a way similar to how incoming folders have been set up on FTP servers for 30-40 years: You can cd into that directory and create/write files, and read any files that you can open, but you cannot list the directory's contents (and optionally, you can create and write any file, but not overwrite an existing one).
Assuming that file names cannot be guessed, this is secure insofar as you can't do much without knowing a file's name. An UUID has 128 bits, but you could use any other random file name of the same or greater size (or a 160-bit random name, if you think 128 bits are not enough).
While it is in theory possible to guess a random 128-bit number (and there is even a chance that two filenames will collide by accident), the chances for such a thing to happen is astronimically small given the time it takes to access a file over the network (which severely limits the number of operations per second that you can do). This is much different from e.g. someone brute-forcing a hash from a stolen password database, where the attacker would typically try a few hundred million hashes per second.
You are probably more likely to die from being hit by a meteor than to ever see this in your life.
Also, a quick Google says that S3 supports folders, so if you are in ultra-paranoia mode, you can create a folder with a UUID name and place your UUID-named files in there. Someone would have to guess a 256 bit number correctly for accessing a file, you can be pretty sure that this won't happen during your lifetime.
The chances of someone randomly guessing a v-4 UUID is infinitesimally small. It's so tiny, it's not worth serious consideration.
Take a look at the math.
The following equation shows the number of guesses (n) required to generate a 50% probability of a correct match is 2.71 quintillion.
n ≈ 0.5+sqrt(0.25+2*ln2*(2^122))
≈ 2,714,922,669,395,445,248
≈ 2.71 × 10^18
Let's increase the probability (p) of a match to one in a billion.
Let: p = 1/(1 billion) = 0.000000001
UUID ≈ sqrt(2*2^122*ln(1/(1-p)))
≈ 103,120,461,418,554
≈ 103.1 × 10^12
I.e., to would take about 103 trillion guesses.
Given these odds, and the compute power required to engineer the hack, the likelihood of someone randomly accessing the UUIDs associated is so low, it just wouldn't be worth losing any sleepover.
Wikipedia has an in-depth description of the model and the use of UUIDs in database keys.
Always assume that any addressable network is hackable. But since your files will be effectively "unlisted" and semi-private using the UUID model should be sufficient to make them virtually inaccessible.
This is a very old post, but there will be people who come across this because it still shows up in google searches. Most of the answers given here are wrong. You should not use UUID as a security mechanism. The answer to the question of "How to secure files in S3" is to use S3 pre-signed URLs.
See documentation here: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
You should not store anything in public S3 buckets that you do not want the entire world to see every day. I won't even mention the potential abuse case this opens you up for - think about data transfer charges for large objects if you get trolled endlessly by a reddit group.
