Moving Away from UUIDs (2018)

https://neilmadden.blog/2018/08/30/moving-away-from-uuids/

by Alupis • 4 years ago

281 230 4 years ago

cetra3• 4 years ago

If you're using them for unguessable random strings then yeah, they're not ideal.

If you're using them for providing a unique id in a distributed system, with very little chance of collision & fitting them in a db column, then they are great.

corytheboyd2• 4 years ago

Yeah I don't really get the point of this article, if you need random values of a specific size don't use uuid, it's literally specified to be one exact length and format.

ejb999• 4 years ago

>Yeah I don't really get the point of this article,

To get clicks?

tejtm• 4 years ago

one exact length and five "versions" of the format (so far)

https://en.wikipedia.org/wiki/Universally_unique_identifier#...

BerislavLopac2• 4 years ago

It is also highly recommended that you include a check digit into it, to minimize the chance of a collision. I've used https://arthurdejong.org/python-stdnum for that purpose.

throwawaymaths4• 4 years ago

Also most well-designed systems only use the UUID as the representation format and use raw bits in performance-critical parts.

_3u10• 4 years ago

Use uint128_t instead.

scott_w3• 4 years ago

The number of comments saying "using UUIDs for secrets isn't that bad" suggests this article needs to be written...

hn_user2• 4 years ago

My only wish is that UUIDs were sortable and still contained their timestamp. When bug hunting, sometimes things become a little more obvious when there is an exact start and end to ids with issues.

myvoiceismypass• 4 years ago

There are KSUIDs that aim to satisfy this

A go ref impl: https://github.com/segmentio/ksuid

dexwiz• 4 years ago

Depends on the version used. Some of them do encode time. But since people don’t like to leak information they use the random version (4).

ilikehurdles• 4 years ago

UUIDv7 is sortable by time but I’m not sure if it’s possible to derive the time stamp from the UUID somehow.

vbezhenar3• 4 years ago

I implemented it myself. Was a little bit tricky, but not rocket science.

Too• 4 years ago

Mongodbs ObjectId has this property.

kube-system2• 4 years ago

I’ve always liked the pattern of putting timestamps on any objects in my DBs.

mirzap• 4 years ago

You can use ULID and store it as UUID since they are the same size. You can check this article for the details:

https://blog.daveallie.com/ulid-primary-keys

Waterluvian• 4 years ago

“Moving Away From Misusing UUIDs”

Alupis7• 4 years ago

There's probably a non-trivial amount of folks that equate a UUID with "unguessable" given their appearance. They are, after all, not sequential and using them to obscure things like number of users (using a UUID in place of an incrementing number) seems like a natural fit.

Given how easy it is to generate a UUID in most languages, and given the low likelihood of a collision within a system - it wouldn't be a huge leap to think UUID's could replace homebrewed random string generators for things like password reset tokens, etc.

withinboredom5• 4 years ago

You can generate sequential UUIDs, IIRC, that’s the best way to store them in a db and still have good partitioning/indexing. I don’t use UUIDs often, but I vaguely remember researching this problem space at some point.

bigiain2• 4 years ago

There's probably a non-trivial amount of folks that equate a UUID with "unguessable" given their appearance.

That's near enough to true for anyone not operating at "web scale".

FAANG/BAT engineers need to care. My systems with 10s or 100s of thousands of users (or, you know, a few thousand users tops) are without doubt going to be re-written (probably several times) well before I have to worry about having so many UUIDs in the wild that this becomes a reasonable thing to worry about.

For me, at the scale of systems I run (or will conceivably run in the medium term future), I think the simplicity/understandability of code that uses native language UUID functions is "the right thing". Whoever does the next big rewrite to support a few million MAU will be thankful they don't have to work out WTF I was thinking when I decided to roll my own random access tokens.

dheera• 4 years ago

Also UUID v3 and v5 produce IDs from identifiers such as URLs which can be quite useful if you want two different systems to generate the same exact UUID given knowledge of the same URL.

For example, in a REST system that needs UUIDs I'd use the REST URL of the object as the UUID.

human• 4 years ago

Something I don't understand: how are UUIDs not safe given that they are probably better than 99.9999% of passwords generated by users?

rr808• 4 years ago

UUIDs are nearly half the mac address of the server + a timestamp. They are in no way random.

nordsieck• 4 years ago

Something I don't understand: how are UUIDs not safe given that they are probably better than 99.9999% of passwords generated by users?

UUIDs are 128 bits. Which is beat by a 5 character a-z random string.

It's certainly possible that they're better than the median password - especially if there isn't a check against a common password list. But it's pretty easy for user chosen passwords to be much, much better.

I strongly doubt that your 6 9s estimate is accurate.

monocasa• 4 years ago

Does your UUID library use a cryptographic safe RNG?

ilyt2• 4 years ago

Pretty much, my first reaction was "people use UUIDs for session tokens ? why? ?

Seems like author made some bad choices in previous systems and now just figured out why tbh.

epicureanideal• 4 years ago

Depending on the UUID algorithm, some are cryptographically sufficient true random, then it would make sense..

hsuduebc2• 4 years ago

From my experience even from bigger companies it is sometimes common practice.

ak39• 4 years ago

Not being snarky: what's the risk of using UUIDs for session tokens if they are created by the server/db and are always verified by server (db) (for authorisation etc)?

jmull• 4 years ago

I’m not sure it’s bad to use a random UUID (v4) generated with a random number generator designed for cryptography for a validated session key.

A guess means making a request to your server. You won’t be concerned with ~2^64 guesses per second.

I’m not suggesting anyone do it, if you have a choice. (Especially consider you’ll probably have to go through the trouble to justify it to people who read articles like this but don’t understand the math.) But if you have an existing system, consider whether you can let it stand.

Ptchd• 4 years ago

If you're using them for unguessable random strings then yeah, they're not ideal.

Why? I like to use them for private/secret URLs ...

echelon• 4 years ago

The best format:

{opaqueTokenTypePrefix}_{crockfordEncodedEntropy}

Also: pass token through a bad words and "credit card lookalike" filter.

Optionally encode author cluster/region details in the low order bytes to resolve before eventual consistency in active-active systems.

zerovox• 4 years ago

The title is misleading. This article argues that you should not use a UUID for a _session cookie or access token_, which was never the intended purpose of a UUID.

hombre_fatal• 4 years ago

I don't think intended purpose cashes out into anything here. Either UUID has enough random bits for your case as a session token or it doesn't. UUID isn't special.

I don't find any variable of TFA's hypothetical UUID-breaker scenario convincing either. Not the number of tokens issued, nor the adversary having Bitcoin network levels of compute, nor the ability to verify tokens at anything close to that speed.

fullstackchris• 4 years ago

yes exactly, who in their right mind would assign a UUID as a session token?!?! i mean, good point, wow, this article proves exactly why UUID shouldn't be used for such... then proceeds to show basically a method that is currently used by many... sigh

Aeolun• 4 years ago

I think the author forgets that while you may (potentially) be able to generate quintillions of UUID’s per second, there is no way you’ll be able to validate that they’re correct at the same speed.

At least, I don’t feel bad saying my server would melt if it had to serve that many requests.

jongjong• 4 years ago

Yeah, since they're trying to guess a random UUID from all issued UUIDs, they would have to make a request for each generated UUID. Even if you assume that ISPs would allow that kind of bandwidth, the entire internet would grind to a half before the attack even began. Also, the 2 * 46 figure used to represent the number of UUIDs is way too large. With proper access control of resources, we only really need to worry about active session IDs and in a world with 8 billion people, there's no way that there would be 2 * 46 active session IDs.

If you assume that every person on earth was hooked to your service 24/7 and ignore the significant bandwidth limitation, it would still take more than 6 months for the entire Bitcoin network to hijack 1 random user's session. But it doesn't make sense to ignore bandwidth limitation anyway since it's the bottleneck. The Bitcoin network computes all these hashes in parallel and there is no way that anything close to this degree of parallelization can be achieved at the network layer.

SkyPuncher4• 4 years ago

While you're not wrong, this is the type of thinking that can introduce security vulnerabilities.

Your current systems might not be able to validate quintillions of UUID's per second, but your future systems might be able to (or at least get a lot closer).

tsimionescu2• 4 years ago

This is also the kind of thinking that people use for public-key cryptography: it's perfectly possible to guess the private key of any TLS cert, for example, it just takes a very long time with today's computers. Future computers may well guess it very quickly, so should we stop using it?

Cryptography is a moving a target. Any cryptographic method except an OTP used with perfect opsec is brute forceable, and will need to be changed when your threat model changes (for example, when computing speed advances significantly).

Matthias247• 4 years ago

+1. Most server deployments will break at less less than 10k RPS. If we talk about the largest scale public cloud deployments, we might end up in the millions to billions of RPS due lots of lots of instances. But the number will be very far off from the 24293141000000000000 rps rate that the author used for estimating the impact.

Plus any deployment that is so large that a user could actually generate a reasonable amount of traffic will likely also have some variant of a DDOS/fraud/rate-limiting protection or at least alarms and manual interventions that will kick in once such a traffic flood is observed.

DethNinja• 4 years ago

It is great that people are concerned about UUID entropy, because some implementations actually got much less than ~120 bits.

However, I think article missed the point that you shouldn’t use UUIDs as a security measure anyway.

indigodaddy• 4 years ago

What about his solution (160-bit (20 byte) random value that is then URL-safe base64-encoded)? Is that a good and properly used security measure for a URL?

fbdab103• 4 years ago

Depending on how many characters of representation you are willing to stomach, I prefer to use a more limited encoding than base64. Something that avoids IL1o0 so that a human could type it without guess work. As your human is not likely to know that you are including "0" but not "o", you have to nix both of them. This only matters if the url has any chance of being read by a human (ie ids). If it is some monstrous 2000 character thing that already contains gobs of metadata, go nuts.

myaccount97862• 4 years ago

Just to be clear, 122 random bits are just fine as a security measure depending on what you want to do. For example, if I have 1 URL and I'm trying to prevent someone from guessing it.

How you choose to encode the bits doesn't affect the security; if you use UUID form it's just as secure as if you use Base64. Regardless, if I had my 122 random bits, you would require 2^121 guesses to have a 50% chance of guessing it.

Edit: this is in the non-quantum case cf. https://en.m.wikipedia.org/wiki/Grover%27s_algorithm

Edit 2: (3:32 ET) done editing

vlmutolo• 4 years ago

Another advantage of UUIDs is that they're more or less monotonically increasing over a medium-to-long time periods. This is very helpful for database insert performance.

kondro• 4 years ago

Not all UUID versions are monotonically increasing. This article is specifically talking about V4 UUIDs which contain random values only.

stop50• 4 years ago

Who the heck stores uuids in their string form. Its only useful for transport. For stoage you use bytes.

postalrat4• 4 years ago

Any time I get what looks like a UUID from a service not under my control and I can't guarantee will always be a UUID.

BeefWellington3• 4 years ago

Sure but at that point you're talking about external systems anyways, and the same would be true for any identifier they give you. One day that int may change into a raw byte array, string, braille, emoji-encoded[1], you name it.

This article is about scenarios where it IS under your control.

[1] https://pypi.org/project/base-emoji/

dspillett2• 4 years ago

You can still store and process it as a large integer, rather than a less efficient string, unless something in your stack is enforcing validation of the version/variant bits.

Unless your concern is more that they may not be unique enough due to bad choices in their derivation function, but this will not change no matter what representation you store them in.

derefr• 4 years ago

If you think you are likely to attract this kind of attention then you might want to carefully consider which side of the Mossad/not-Mossad threat divide you live on and maybe check your phone isn’t a piece of Uranium.

To be honest, we get something like this kind of attention (Tbps of forged requests / brute-force registration attacks per day), and all we do is provide a free API that's rate-limited per user account for multitenant-QoS reasons. People do all sorts of crazy stuff to try to sneakily drip-register a thousand accounts over several weeks so they can then launch some big job that uses all the keys in tandem to evade the rate limits.

Little do they know, they don't get any benefit from that, even while they're nominally "getting away with it"; doing that just makes our servers fall over! :P

---

Separately, you should really consider a level between "Mossad" and "not-Mossad": the sorts of people who hack crypto exchanges. They tend to use exactly the kind of "saw it in a movie"-level techniques that you'd think wouldn't happen because "you can just use rubber-hose cryptanalysis." Except if you're a socially-anxious math-genius fifteen-year-old living in Belarus, and there's a cryptosystem that you have unlimited access to a local copy of, maybe the rubber-hose cryptanalysis is actually harder!

323• 4 years ago

you should really consider a level between "Mossad" and "not-Mossad": the sorts of people who hack crypto exchanges.

Bad example, since the biggest crypto hacker is North Korea.

North Korean government-backed hackers have stolen the equivalent of billions of dollars in recent years by raiding cryptocurrency exchanges, according to the United Nations. In some cases, they’ve been able to nab hundreds of millions of dollars in a single heist, the FBI and private investigators say.*

https://edition.cnn.com/2022/07/10/politics/north-korean-hac...

naet• 4 years ago

I always wonder about these "North Korean" hackers given that I've heard the average North Korean citizen's access to computers (and the outside internet) is extremely limited. Where are they getting these world class hackers from if this is the case?

It must be a group of outside parties who use North Korea as a mask and/or employer, right?

matai_kolila3• 4 years ago

Uh, I doubt many/any of them are “crack a crypto algorithm” sophisticated.

These groups know how to buy exploits, attach payloads, and be persistent. Not trivial per se but hardly PhD math stuff…

adamrezich• 4 years ago

(2018), previously: https://news.ycombinator.com/item?id=25307097

edflsafoiewq3• 4 years ago

I've never understood why UUIDs are... a thing. I understand how it can useful to have a name for different kinds of identifiers, but what is the purpose of adding variant/version bits and unifying different kinds of IDs into a single thing called a UUID? The article for instance never did anything with the "UUID-ness" of the IDs so they might as well have started with "random 128-bit integers".

Can anyone explain this?

yawnr• 4 years ago

One reason is web scraping. Twitter used to have sequential IDs that made it easy to tell how many users they’d added over a period of time, even after they were public.

vanviegen6• 4 years ago

How do random 128 bit IDs not fix this problem?

dredmorbius• 4 years ago

Google+ UIDs were UUIDs (or something looking very much like them).

They were nonsequential and sparse.

For those of us looking to 1) quantify activity and 2) migrate users and data off the system, they were pretty confounding.

Fortunately, Google also provided lists of those UUIDs by way of robots.txt sitemap files.

I used one sample of ~50k of those to estimate total G+ active users as of ~2014 (another group polled a random sampling of 500k for a more precise measurement). And when G+ folded in 2019, I'd provided that information plus some additional bits gleaned over the years and from some additional sources to estimate just how large the archive dataset might be, for ArchiveTeam.

One place where the sparse population might prove really useful is in telephony. Phone numbers as we know them today are densely populated, and in fact, frequently re-used (which is why your new phone is receiving debt-collection calls for its previous holder). It also makes war-dialing or random-dialing viable for robocallers.

If only 1 in 10 billion numbers was valid (about the saturation rate of G+ UUIDs), war-dialing / random dialing would be all but ineffective. If you could dial one number per second, you'd have a 50% chance of hitting a live number ... in 158 years.

(Of course, if you had a listing of valid numbers, again, see G+'s robots.txt files, your search space would be far smaller.)

crazygringo2• 4 years ago

They're for distributed systems.

The entire point is that different computers can generate ID's that can be merged in a database later on and not collide.

And the way they're designed is less likely to collide than random numbers are. (But you need to pick the appropriate UUID version to ensure that, depending on your system's architecture.)

If you're generating ID's that originate in a single centralized table, you don't need UUID's -- autoincrement or random integer is the simpler choice.

vanviegen6• 4 years ago

You don't need a UUID for that. A 128 bit random integer will work just fine. Better even, as no bits are wasted on meta data.

edflsafoiewq3• 4 years ago

Okay, thanks. Thinking about it a little more I think I get it.

1. We want a single truly universal namespace.

2. We want to have different methods of generating IDs, since there are a lot of different people in the whole universe and they may have different needs.

3. Each single method is designed to not generate collisions.

4. But there could be collisions between different methods. So some bits are added to show what method was used to generate the ID to guarantee IDs generated by different methods don't collide. This is also why we need a spec that defines what each method is, the versions are like a scare global namespace that needs to be allocated carefully.

I think the reason I found this difficult is most of the times I see UUIDs, (1) and (2) aren't actually needed (this article being representative).

amelius• 4 years ago

And what are the hyphens good for? And what is the reason for their irregular placement?

wsc981• 4 years ago

My guess would be readability. Easier to "parse" by humans then just a long string of numbers and letters without "interpunction".

eric4smith• 4 years ago

I had a database table where I used UUID as primary key. Big mistake. Haunts us to this day.

Not sortable. Takes a lot of space. Table relationships are annoying. Etc.

What we do instead is have a secondary UUID key and keep Bigint as primary keys. Then use the UUID column in the external context instead.

UUIDs are fine for 99.99999% of the time in your own domain.

Don’t expect universal uniqueness across all domains.

Alupis7• 4 years ago

This is a good approach. I wonder if using a UUID-aware data type (like PostgreSQL's UUID type) would improve performance without making the second column necessary?

dvnguyen• 4 years ago

Just curious to learn: when do you need sortable primary keys?

postalrat4• 4 years ago

When you need to get a sorted list or perhaps a range?

When do you need primary keys?

code_runner• 4 years ago

In sqlserver (and others?) you can have one clustered index. Typically this is the primary key (doesn’t have to be though).

The clustered index is actually the physical order of the data stored on disk, so any new guid causes tremendous amounts of churn.

Not sure how modern this concern is, but I would guess a LOT of SASS companies have to consider this.

Quick edit: sequential GUIDs are obviously a thing and I believe alleviate a lot of these concerns. I do not believe that was an option in sql server 2008 r2 (a version that lived a LONG time).

winrid2• 4 years ago

It makes pagination much more efficient and possible to completely use an index (re: data is pre-sorted) if you have some sort of increasing id, vs sorting in-memory on request. Even having some sort of indexed "createdAt" field, and sorting on that, isn't super reliable for pagination when the dataset is changing. You usually want a stable sort to make pagination nice, so you add an ID to it, but then this gets very inefficient w.r.t index use if the PK is a UUID since it is not monotonic/sortable.

sicp-enjoyer3• 4 years ago

Almost every database algorithm is based on ordering and binary search.

JSavageOne• 4 years ago

When is an instance you'd need to sort by ID? How does it make table relationships annoying?

biztos• 4 years ago

I’m not the parent but for me:

1. Sort by ID if you want to see things by insert order and are using serial/autoincrement for the PK.

2. Writing (or reading, or talking about) SQL queries in which the IDs are present.

I solved the first problem by using ULID at one point but in future I’d probably not use a UUID until I had a specific need for it. And as others have mentioned, if that need is about the outside world I’d probably go with an extra column.

dragonwriter2• 4 years ago

The reason to use UUIDs as primary keys is to allow creating records including primary keys outside of the database before posting them, especially in distributed systems.

UUIDs are sortable, but don’t give you creation-order sorting (of course, its abusing bigint PKs to rely on them for that, too.) If you want creation-order sorting, storing a creation timestamp and sorting on that works, and I’ve never had a db that had a business requirement for creation order sorting and didn’t also have one for actual creation time.

Alupis7• 4 years ago

I've become of the mindset that most records should have creation and update timestamps - even if you do not currently plan to use them. They might come in handy later, and the code to implement them in most languages/frameworks is trivial anyway.

sa462• 4 years ago

What's the benefit of having the primary key before the row is stored in the database?

Maybe concurrent inserts to multiple data stores so you don't need to wait for an initial ID from the database. You'd have to trust the client to give you a “good” UUID as well as the normal distributed problems of one of the RPCs failing. I know both Twitter (called Snowflake iirc) and Google have unique ID services for this use case.

theptip• 4 years ago

These days ULID (https://github.com/ulid/spec, or any of the variants), or most recently the new UUID versions (https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...) give you creation-order sorting.

Quarrelsome2• 4 years ago

AFAIK UUIDs as pks in databases is extremely standard. I would suggest the biggest downside is debugging where writing id = 5 is much easier than id = 'xxxx-xxxx-xxxx-xxxx'.

vbezhenar3• 4 years ago

On the other hand you won’t get wrong result if you wrote wrong table name. Was hit once. Deleted row from the wrong table.

lyu07282• 4 years ago

Everytime I used uuids before I always ended up with terrible index performance

smileysteve• 4 years ago

But to use both, you have to store both, to use it as a lookup, you have to [unique] index both; you can no longer easily partition (and guarantee uniqueness)

And an auto incrementing bigint doesn't guarantee order.

Kamq• 4 years ago

Takes a lot of space

Wait, did you store them as strings instead of as a native UUID type (or any sort of 128 bit integer type)?

Alupis7• 4 years ago

Storing UUID's in their binary format quickly becomes a PITA for debugging or doing manual queries. Some DB's have functions that can convert to human-readable strings which make this less painful, but it's never going to be as simple as using integer id's.

As with all things, there are tradeoffs that must be considered before building the system.

SAI_Peregrinus• 4 years ago

And if you need universal uniqueness across all domains, just pick a 256-bit random number using a CSPRNG like /dev/urandom.

sicp-enjoyer3• 4 years ago

I'm surprised to hear it's not sortable. Why can't they just memcmp it?

deathanatos5• 4 years ago

You can and databases do.

What people want is for it to be sortable by generation time, i.e., they want it to share the "larger values were generated later" property of timestamps (but without collisions) or SERIALs (but without the locking on the serial / independent generation).

deathanatos5• 4 years ago

Not sortable

That's not correct; its trivial to come up with an ordering, and I don't know of a database in practice that doesn't permit sorting on a UUID.

Table relationships are annoying

… in SQL,

  user_id REFERENCES users

It's exactly the same, regardless of the type of the column…?

Takes a lot of space

Yes … but also no. It's 16 B vs. a serial's 4 B, I grant, but compared to a varchar, it's immaterial. (And particular in comparison to the number of times I see people use a varchar for an enum…) Certainly there could be a case where a row is wide b/c of UUIDs, but in practice, rows are wide either because of the data, or because of poor design.

insanitybit3• 4 years ago

Yeah, I mean, in general you should always think about how much entropy you need and know how much you're getting. I think it should be fairly standard knowledge that a UUID may only provide 122 bits of entropy, but then again what should be standard is not what is standard.

It should also be standard to understand the birthday paradox and when it's relevant.

In a ton of cases 122 bits is totally acceptable and it's really up to you to understand when it isn't. In fact, in lots of cases you can get away with less, like 96bits, etc.

It should be pretty easy to answer "how much do you need?" by asking what your tolerance for collisions is.

akira2501• 4 years ago

Assuming a basic 4 bits of entropy per character, then you'd need a 30 character password to have as much entropy as is encoded in your GUID. If they're worried about 122 bits of GUID entropy, but their passwords are shorter than 30 characters, it feels like they misplaced their worry.

insanitybit3• 4 years ago

The issue isn't really passwords where a UUID would be totally overkill, it's for things like capabilities. For example, I could put a file at `example.com/<some uuid>` and no one could find it unless I told them about it. As the author points out, my chance of an attacker guessing that url isn't 2^128 but instead 2^122. For many cases that's actually fine.

stillbourne• 4 years ago

I need 10^157 bit of entropy.

ComplexSystems• 4 years ago

The title of this article is as misleading as it could possibly get.

The author's recommendation is to make UUID's longer and encode them with base 64 instead of hexadecimal. That's it. Somehow that means "moving away from UUID's."

scintill76• 4 years ago

UUIDs are 128 bits by definition. So there is no such thing as a “longer UUID”, but if you use that concept then you are indeed “moving away from UUIDs.”

Joel_Mckay• 4 years ago

I prefer encoded GUID generators like: pid, memory location, machine hardware ID, UTC epoch date-time, back-patched hash( serialized object, and salt)

Guaranteed globally unique in concurrency, built in data integrity check, and non-blocking read-modify-Bork resistant error detection

You are welcome, =)

andreygrehov• 4 years ago

Does anyone have experience with KSUID (K-Sortable Unique IDentifier) ? Interested in cons.

jasonwatkinspdx• 4 years ago

TL;DR: if you want the chance of a collision to be the same as hard drive corruption, you're "safe" with 128 bit random ids until nearly a trillion objects. That doesn't mean it's a particularly great idea though because you have to not just look at the probability of collision but what net impact that will have to the system/business as a result.

If you want future proof random/unsorted ids just use 512 bits. That's large enough to maintain a 128 bit search space with existing hash algorithms even in a world with practical quantum computers that run Shore's et all. This is approximate reasoning not a formal proof but is reasonably grounded. In the big picture 64 byte vs 16 byte ids are unlikely to be the thing that kills your company. A security breach or corruption of a key database record very well could.

semireg• 4 years ago

I rather like how stripe uses prefixes for all of their object IDs returned from the API.

A charge looks like: ch_3M0k8bFSpHML0ApB0Pd8Zxmq

gcoguiec• 4 years ago

Some UUID alternatives:

- https://github.com/ai/nanoid

- https://github.com/segmentio/ksuid

- https://github.com/ulid/spec

SkyPuncher4• 4 years ago

IMO, this is bad math and why you probably need to be more cautious. I actually went through similar math with my team last year.

* It's long been know that UUID should never be used as a security mechanism. While the math is interesting, the fact they're using it as justification for moving away from UUIDs is concerning. It'd be like publishing a post titled "we're moving away from MD5"

* If you're using these tokens for human-entered purposes, you should implement account based rate limiting. It's nearly impossible for a brute force attack if a single account can only have, say 100 attempts per day before contacting support. There are very very use cases where a human-based token will ever need more than 20 attempts per day.

* Use long, high-character count tokens if they're intended to be machine/copy-n-paste only. Storage is cheap. Use something big and long.

Seriously, rate limit your shit. The second that rate limits are introduced you control all of the major variables in your security posture.

dopidopHN• 4 years ago

Exactly the article glossing over rate limiting and proceeding to do some math without it kinda ruined the article for me.

The minute is rate limited it’s crumble.

skybrian• 4 years ago

If the attacker doesn't care which account they break into, they could try a different account each time and then account-based rate limiting doesn't help as much.

(Depending on how many accounts there are that they can try.)

SkyPuncher4• 4 years ago

Generally, the subject tokens (short-ish, human enterable tokens) should only be active on a fraction of your accounts at any one time.

pkulak• 4 years ago

Hopefully they aren't able to get a list of all your user accounts. The IDs should not be iterable (like a UUID, for example!), and the friendly name (like an email address) is private information that shouldn't be getting out.

tgv• 4 years ago

I've got a UUID in the URL of a new system (not a real UUID, but 128 random bits encoded in the UUID format), because that kept the existing links active. If someone were to guess one (which isn't that interesting, BTW, it's not account info or anything like it), he'd have a hard time checking a million per second, because the response is never going to be faster than 10ms or so.

hn_throwaway_99• 4 years ago

Sorry, but the main point of this article goes under YAGNI or "no, you aren't Google" for me.

If you aren't generating a thousand IDs per second for every person on the planet, you're fine.

Even from a guess-ability standpoint, it's more important to put reasonable rate limits on your endpoints than worrying about someone putting bitcoin-network-level of resources against your endpoints.

tracker1• 4 years ago

Having had to this past week work on scrubbing a codebase looking for hard coded values... I will say, the prominence of the UUID format was at least very beneficial when searching beyond the configuration files. [\w\/_+-]{20,} also worked for finding longer matches, but more noise.

I'm not sure it's worth it to use more than a UUID for some use cases, but for a lot, it's fine. Maybe CUID if there's a decent library for your language/platform.

Aside... Whoever makes such a system that is generating/receiving OAuth tokens at that rate, and won't see/detect/feel a brute force attack of that scale probably didn't do anything to protect their SMS verification codes (only 6 digits), you'll definitely brute force that against a known password breach far more quickly, but okay, in either case.

systematical• 4 years ago

I figured this would be an article giving reasons not to use UUIDs as database identifiers...

jurschreuder• 4 years ago

This article is totally wrong about everything.

An id is not a password.

Hash rate is totally not comparable with just trying every combination.

You can generate combinations instantly, you dont need a gpu for that.

The delay is how long the server takes to respond and how many connections it can have at the same time.

You're also blocked by the server after trying a couple of thousand.

myaccount97862• 4 years ago

I find that 160 bits is a sweet spot of excellent security

Please, for the love of God, leave cryptography to the cryptographers.

ctopher7• 4 years ago

I think we don't need to reinvent the wheel for handling user session, especially in web based application. There are common best practices that everybody already know such as using jwt, https and store in http only cookie

avodonosov• 4 years ago

I prefer z-base-32 rather than url-safe base64.

doty• 4 years ago

Am i mis-reading this article?

BESIDES not having any particular way to validate a token without asking the service, making the rate a hell of a lot slower than 2^64 tokens per second (lol wut) doesn’t it also assume that you have 2^46 valid tokens in existence? Isn’t that 70 TRILLION valid tokens, or nearly 9000 tokens per human on earth?

opvasger• 4 years ago

UUID, as the name implies, is used for identifiers - You know this.

These use-cases you're implying seem to be the real problem.

smaudet2• 4 years ago

On the flip side UUIDs are great as non-cryptographic identifiers...

It's easy to get and for any non sec application nearly impossible to replicate.

felixr• 4 years ago

The dash-separated hexadecimal format takes 36 characters to represent 16 bytes of data.

You can use a different formatting. I would suggest looking at https://github.com/oculus42/short-uuid Of course if you just want a random ID, then you might not need a UUID. But UUIDs have the advantage that there are different versions and you can distinguish them; e.g. you might want a unique ID that gives you some debugging information (where/when was it created), so you use v1 and later you can decide to switch to v4 if decide you want the IDs to carry no information.

Indepedent of how you generate the ID, I think the base-57 encoding that shortUUIDs use is quite good when the IDs are user facing. Not using O,0,l,1,I in the alphabet makes IDs more readable.

langsoul-com• 4 years ago

Should rename the article to be more accurate. Why you shouldn't use uuids for a token password.

daneel_w• 4 years ago

Unlike the UUID scheme, strings of completely random characters don't sort/tree-index very well. Apart from that they are, in my opinion, a much better alternative.

agilob• 4 years ago

There are different types of UUID that serve different purposes https://web.archive.org/web/20220623031329/https://www.ietf....

cryptos• 4 years ago

I really like https://github.com/ai/nanoid which is available for a wide range of programming languages. It creates short, random, and URL-safe IDs.

sorokod• 4 years ago

Few things say amateure more than calling random values pretty unique

javajosh• 4 years ago

Hello. I tried my hand at writing this in JavaScript. See: https://codepen.io/javajosh/pen/BaVrBMb?editors=0010

Moving Away from UUIDs (2018)

Related Stories