Hacker News Reader

Comment by tlb | Hacker News Reader

The guideline for unguessability in that TR just says to use a UUID. UUIDs are ugly, and quite long for the amount of randomness they contain. I prefer Slack's new 10*base36 solution.

View on HN

10 base-36 digits is only around 52 bits, compared to the 112 random bits in a UUIDv4. 2^52 might be enough for particular use-cases, but it's nowhere near a UUID in terms of randomness. Even 10 base-64 digits is only 60 bits.

UUIDs are often guessable, too, so that recommendation is just plain wrong (or at best, woefully incomplete).

Right, some kinds of UUIDs achieve their uniqueness precisely by leveraging predictability. The unpredictable kind are mostly just random bits formatted in a particular (not very efficient) way.

The random ones don't have to be unpredictable randomness, either. For example, you might seed a good RNG with the local MAC address and boot time and then use that to generate v4 UUIDs. As far as I can tell, this would be perfectly legal and should produce UUIDs that are as likely to be unique as any other, but they would also be easy for an attacker to predict.

Basically the whole "version" UUIDs is a stupid fever dream. Any sane implementation should return 16 random bytes and be done. The fact that there's a spec for this and it's longer than 2 sentences is just wrong.

I think they were just afraid of the birthday paradox. But I agree, just grabbing some random bytes really is the way to go.

Although, I'm a bit afraid of the birthday paradox, maybe we should use 20 bytes instead....

The idea that a UUID should have a "version" and the random one uses 122 bits instead of 128 bits sorta makes ya wonder how concerned they were.

Yeah, spot on. At least now in 2015 using 16 bytes for id's and hashes no longer seems like a lot of memory or storage.

It pains me to see people inventing weird id schemes for every app and api.

Reply on news.ycombinator.com