31–40 of 53 posts
Earlier quoted context omitted.
w3 has some guidelines on capability urls: http://www.w3.org/TR/capability-urls/
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.
Earlier quoted context omitted.
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.
UUIDs are often guessable, too, so that recommendation is just plain wrong (or at best, woefully incomplete).
Earlier quoted context omitted.
w3 has some guidelines on capability urls: http://www.w3.org/TR/capability-urls/
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.
Earlier quoted context omitted.
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.
A few years ago, I wrote a little js tool to browse random Imgur images by guessing their urls (i.imgur.com/) until it found one that succeeded. It would add the found image to an infinite-scrolling page. It was kinda fun to browse, and a lot of people seemed to enjoy playing with it.
After a couple years, though, Imgur suddenly started blocking access to their images on my site. It turned out they were blocking based on the referrer header.
I emailed them asking what was up, and apparently they were attempting to ensure the privacy of public-url images by manually going after any tools like mine (if you google 'random imgur', you'll find dozens).
I didn't bother circumventing this, I didn't want to be a jerk just to prove a point. I did try to point out that there were a number of ways to get around something as simple as a referrer block, but I don't think the customer support person I was dealing with was really interested in discussing the issue and I let it drop.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
The good news is that github puts a uuid in the url, so its unguessable. Slack, on the other hand, didn't have a big unguessable number... they had a very small number you could brute-force.
UUIDs are (usually) generated in a systematic fashion, so large parts of them are often possible to determine ahead of time.
Earlier quoted context omitted.
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.
Although, I'm a bit afraid of the birthday paradox, maybe we should use 20 bytes instead....
Dude! You have got to take a better profile picture. Really? Smug eastern block open collar look with an earbud in? No good. No good at all.