So recently, this popped up (, which is a terrible post about how you shouldn’t use UUID’s for session keys. uses UUID’s for session keys, so I wanted to write something about why that’s not a bad idea.

First, let’s talk about how random a random UUID is. A UUID is 128 bits, of which 122 are supposed to be random. That’s a lot of randomness, really, anything over 96 bits is plenty of randomness for an online only service. If you can guess at something locally, you’d want more like 160 bits of randomness (or more), but that’s not the case here.

So, let’s talk numbers. If we assume the site will have a million active session at any given time, that eats around 20 bits of randomness. That leaves us with 102 bits of randomness.

Now, let’s talk about how many guesses you can make per second. Let’s assume I’m willing to pay $10,000 a month in hosting costs (I won’t, but let’s assume I’m willing to pay that). That will buy you 15 billion guesses a month. That’s 6,000 guesses a second or 13 bits worth of randomness.

In order to guess a valid session key, you would need 2^(122-20-13) seconds, or 618,970,019,642,690,137,449,562,111 seconds, or 19,500,000,000,000,000,000,000,000 years.

Yeah, that’s a lot of time. I don’t need to switch off of UUID’s for session keys for a long time.

For 96 bits of randomness in a session key, it would be 292,000,000,000 years. That’s still well after our sun dies, and very long after the code will no longer understand what the date is (275,760 CE).

While it may seem that hosting expenses are quite high, that is for a ludicrously high number of requests per second for this category of site. If it actually grew to that point, I would have plenty of time to move it to a different kind of hosting that would be much cheaper. Normal amounts or even high amounts of traffic for the site cost in the range of $0-10 a month.

Note that these numbers are for a minor site like this. If you’re Google, you can and should use longer session keys.