12 ms·

Moving Away from UUIDs (2018)

281 points by Alupis 4y ago

cetra3 4y 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.
- corytheboyd 4y 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 4y ago
    >>Yeah I don't really get the point of this article, To get clicks?
    - corytheboyd 4y ago
      You're not wrong lol
    - sieabahlpark 4y ago
  - tejtm 4y ago
    one exact length and five "versions" of the format (so far) https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions https://en.wikipedia.org/wiki/Universally_unique_identifier#...
    - adileo 4y ago
      I made a comparison list with the most known uuids out there, a couple of days ago, it was quite fun discovering all the different kinds of uid and their pros/cons. https://adileo.github.io/awesome-identifiers/ https://adileo.github.io/awesome-identifiers/
      - djbusby 4y ago
        ULID example should be in uppercase. Love this chart tho.
      - JimDabell 4y ago
        KSUIDs are fairly popular and missing from your list: https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid
        8n4vidtmkvmk 4y ago
        what's the resolution on those? 32 bits, 100 years.. that seconds right? doesn't sound excellent for time ordering. 100 years also seems a little short but at least I'll be dead
        sekh60 4y ago
        Don't look at it as being your problem in 100 years, but as helping employment in 100 years and helping the economy ;)
      - bmn__ 4y ago
        https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#page-4 https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...
  - BerislavLopac 4y 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 https://arthurdejong.org/python-stdnum for that purpose.
    - sokoloff 4y ago
      I don't see how a check digit minimizes the chance of collision. (Here, I'm assuming that a check digit is calculated from the other digits. What am I thinking about incorrectly?)
      - georgemcbay 4y ago
        Looking at the docs for the library linked, it appears to be a Verhoeff algorithm check digit... so yeah, you're correct. This is effectively a simplistic stand-in for a CRC type system -- useful to detect if the data has been corrupted, but not useful to avoid collisions.
        TedDoesntTalk 4y ago
        And if someone is worried about UUID collisions, they need to rethink their priorities in life.
      - BerislavLopac 4y ago
        You are correct, this should teach me not to write comments when I'm too tired. :/ The check digit wouldn't really help with collisions, since if the strings are the same the digit will be too. They are primarily useful when we need to ensure correctness on human input.
  - throwawaymaths 4y ago
    Also most well-designed systems only use the UUID as the representation format and use raw bits in performance-critical parts.
    - lolinder 4y ago
      The raw bits are the UUID, the hex string is just a human-readable representation that also plays nicely with JSON.
      - throwawaymaths 4y ago
        Tell that to Django (well 5 years ago anyways iirc, don't know what it does now). Pretty sure it used to store uuids as strings columns in your sql.
        lolinder 4y ago
        Yep, looks like it does the right thing in PostgreSQL but not anywhere else [0]. https://docs.djangoproject.com/en/4.1/ref/models/fields/#uuidfield https://docs.djangoproject.com/en/4.1/ref/models/fields/#uui...
        throwawaymaths 4y ago
        I feel like it did strings in postgres too, not too long ago and I had a <brain explode> moment when I worked on a codebase and had to figure out why queries were terrible
        lolinder 4y ago
        Supposedly the behavior hasn't changed since at least version 1.8: https://docs.djangoproject.com/en/1.8/ref/models/fields/#uuidfield https://docs.djangoproject.com/en/1.8/ref/models/fields/#uui... It may not have worked correctly on your project for some reason?
        4y ago
  - _3u10 4y ago
    Use uint128_t instead.
  - scott_w 4y ago
    The number of comments saying "using UUIDs for secrets isn't that bad" suggests this article needs to be written...
- hn_user2 4y 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 4y ago
    There are KSUIDs that aim to satisfy this A go ref impl: https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid
    - scrollaway 4y ago
      Also, UUIDv6, v7 and v8. Still a draft. https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#page-8 https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...
  - dexwiz 4y 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).
    - andreareina 4y ago
      They're little endian so not sortable
      - sgtnoodle 4y ago
        What does that have to do with anything?
        andreareina 4y 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. >>> Depends on the version used. Some of them do encode time. Encoding time isn't enough, it has to be big endian (unless you write a special sorting function for uuids). Timestamped uuids store the timestamp as [timestamp_low, timestamp_mid, version(!), timestamp_high][1] which doesn't sort right. [1] https://en.m.wikipedia.org/wiki/Universally_unique_identifier https://en.m.wikipedia.org/wiki/Universally_unique_identifie...
- Waterluvian 4y ago
  “Moving Away From Misusing UUIDs”
- Alupis 4y 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.
  - withinboredom 4y 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.
    - Alupis 4y ago
      I think most languages let you chose which version of UUID you want - with most defaulting to the random version (I think 4?) by default. There are other versions that are sequential/time-based though, but using these could open the door to de-obfuscating whatever data you wanted to protect via UUID's in the first place (like how many sales orders you receive per hour, etc).
      - withinboredom 4y ago
        I don’t think uuids are designed for obfuscation, though they certainly help with that as a side effect. I could be wrong though, I’ve never looked into it.
        Alupis 4y ago
        They (randomized type 4 UUID's) obfuscate as a side effect because they are much more difficult to guess due to their randomness. As the article points out though, they are not impossible to guess... but it will come down to your risk tolerance and what the UUID's are "protecting". People like to reach for UUID's when obfuscation is needed because inventing your own duplicate-aware random string algorithm isn't what most folks want to spend their time thinking about. Plus, these days, many databases come with UUID-aware data types that make using UUID's fairly straight forward.
- dheera 4y 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 4y 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 4y ago
    UUIDs are nearly half the mac address of the server + a timestamp. They are in no way random.
    - throwanem 4y ago
      That's UUID v1. The random one that everyone uses is v4.
      - kube-system 4y ago
        I have seem some common libraries that default to v1, so I can see why there’s some confusion in here.
  - nordsieck 4y 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.
    - prutschman 4y ago
      A 5 character a-z random string has log2(26^5) =~ 23.5 bits of entropy, way less than 128.
    - deleted 4y ago
      [deleted]
    - andreareina 4y ago
- ilyt 4y 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 4y ago
    Depending on the UUID algorithm, some are cryptographically sufficient true random, then it would make sense..
    - ksidudwbw 4y ago
      what if you sha it?
      - WirelessGigabit 4y ago
        That actually reduces the usefulness as you're hashing the data into a smaller length.
        unlikelymordant 4y ago
        It seems uuids are 128 bit, while sha is 160 bit. There is also sha256 and sha512 for longer hashed. So there shouldnt be any worries about the hash being shorter.
        markatto 4y ago
        Yes, some hashes might not meaningfully hurt it, but they won’t add any entropy, which is the real problem.
        jchw 4y ago
        Rereading I am guessing you're merely pointing out that the comment regarding shortening the length is untrue. If you already understand the entropy issue here, please treat my "you"s as royal you's. You have a 128 bit value. That's 128 binary digits. Each digit can be zero or one. That means you have 2^128 possible distinct values. (Ignoring the fixed bits in UUIDs since it's not important for sake of this argument.) Now you use a one-way cryptographic hash on top, like sha256. This will return a specific hash for any given input. It is always the same for a specific given input, and it is nearly always distinct. The output that a hash has may have more bits, but the number of distinct values can't increase; it can only ever decrease. That's because you could only ever give it 2^128 different values. How could it ever return more outputs if each input corresponds to one output? To make it more clear, let's say you have a database where you want to store a customer's zip code so you can use it as some kind of validation later on to ensure it matches, but you don't want to store it in plaintext, so you hash it. The hash is 160 bits. Secure, right? Wrong. There are less than 50,000 zip codes. It would be trivial to calculate the hash of every single one and use it as a simple hashmaps from hashed value to plaintext. You may be thinking this is impractical for an input domain as large as 2^128, but realistically it only adds a slight roadblock. Knowing the only valid values will be hashed UUIDs, instead of picking 160 random bits, you'd be much better off picking a random UUID, hashing it, and trying that for each attempt.
- Ptchd 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
- SkyPuncher 4y 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).
  - tsimionescu 4y 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).
DethNinja 4y 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 4y 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 4y 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.
- myaccount9786 4y 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 https://en.m.wikipedia.org/wiki/Grover%27s_algorithm Edit 2: (3:32 ET) done editing
vlmutolo 4y 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 4y ago
  Not all UUID versions are monotonically increasing. This article is specifically talking about V4 UUIDs which contain random values only.
stop50 4y ago
Who the heck stores uuids in their string form. Its only useful for transport. For stoage you use bytes.
- postalrat 4y 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.
  - BeefWellington 4y 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/ https://pypi.org/project/base-emoji/
  - dspillett 4y 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 4y 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 4y 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-hackers-crypto-currency-firms-infiltrate/index.html https://edition.cnn.com/2022/07/10/politics/north-korean-hac...
  - naet 4y 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?
adamrezich 4y ago
(2018), previously: https://news.ycombinator.com/item?id=25307097 https://news.ycombinator.com/item?id=25307097
edflsafoiewq 4y 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 4y 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.
  - vanviegen 4y ago
    How do random 128 bit IDs not fix this problem?
  - dredmorbius 4y 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.)
eric4smith 4y 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.
- smileysteve 4y 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.
- Alupis 4y 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 4y ago
  Just curious to learn: when do you need sortable primary keys?
  - postalrat 4y ago
    When you need to get a sorted list or perhaps a range? When do you need primary keys?
    - endisneigh 4y ago
      that doesn't really make sense though. how would you know the range to sort by? presumably you'd use the criterion directly to sort. a better reason and justification to not use UUIDs is that they take up needless space if you're space constrained. they also have worse performance
      - 4y ago
insanitybit 4y 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 4y 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.
  - insanitybit 4y 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.
    - vbezhenar 4y ago
      It’s 2^122. Or 2^128 if you don’t care about stupid standards (why would you). Birthday paradox is about getting collisions, not guessing.
      - insanitybit 4y ago
        Right, yes, guessing once specific uuid wouldn't be subject to the birthday paradox, thanks. Edited my post to no longer reflect that.
stillbourne 4y ago
I need 10^157 bit of entropy.
ComplexSystems 4y 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 4y 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 4y 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 4y ago
Does anyone have experience with KSUID (K-Sortable Unique IDentifier) ? Interested in cons.
jasonwatkinspdx 4y 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 4y 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 4y ago
Some UUID alternatives: - https://github.com/ai/nanoid https://github.com/ai/nanoid - https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid - https://github.com/ulid/spec https://github.com/ulid/spec
SkyPuncher 4y 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 4y 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 4y 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.)
  - SkyPuncher 4y 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 4y 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.
hn_throwaway_99 4y 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 4y 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 4y ago
I figured this would be an article giving reasons not to use UUIDs as database identifiers...
jurschreuder 4y 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.
myaccount9786 4y 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 4y 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 4y ago
I prefer z-base-32 rather than url-safe base64.
doty 4y 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 4y 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.
smaudet 4y 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 4y 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 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 4y ago
Should rename the article to be more accurate. Why you shouldn't use uuids for a token password.
daneel_w 4y 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 4y ago
There are different types of UUID that serve different purposes https://web.archive.org/web/20220623031329/https://www.ietf.org/id/draft-peabody-dispatch-new-uuid-format-03.html https://web.archive.org/web/20220623031329/https://www.ietf....
cryptos 4y ago
I really like https://github.com/ai/nanoid https://github.com/ai/nanoid which is available for a wide range of programming languages. It creates short, random, and URL-safe IDs.
sorokod 4y ago
Few things say amateure more than calling random values pretty unique
javajosh 4y ago
Hello. I tried my hand at writing this in JavaScript. See: https://codepen.io/javajosh/pen/BaVrBMb?editors=0010 https://codepen.io/javajosh/pen/BaVrBMb?editors=0010

281 points by Alupis 4y 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.

corytheboyd 4y 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 4y ago
  >>Yeah I don't really get the point of this article, To get clicks?
  - corytheboyd 4y ago
    You're not wrong lol
  - sieabahlpark 4y ago
- tejtm 4y ago
  one exact length and five "versions" of the format (so far) https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions https://en.wikipedia.org/wiki/Universally_unique_identifier#...
  - adileo 4y ago
    I made a comparison list with the most known uuids out there, a couple of days ago, it was quite fun discovering all the different kinds of uid and their pros/cons. https://adileo.github.io/awesome-identifiers/ https://adileo.github.io/awesome-identifiers/
    - djbusby 4y ago
      ULID example should be in uppercase. Love this chart tho.
    - JimDabell 4y ago
      KSUIDs are fairly popular and missing from your list: https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid
      - 8n4vidtmkvmk 4y ago
        what's the resolution on those? 32 bits, 100 years.. that seconds right? doesn't sound excellent for time ordering. 100 years also seems a little short but at least I'll be dead
        sekh60 4y ago
        Don't look at it as being your problem in 100 years, but as helping employment in 100 years and helping the economy ;)
    - bmn__ 4y ago
      https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#page-4 https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...
- BerislavLopac 4y 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 https://arthurdejong.org/python-stdnum for that purpose.
  - sokoloff 4y ago
    I don't see how a check digit minimizes the chance of collision. (Here, I'm assuming that a check digit is calculated from the other digits. What am I thinking about incorrectly?)
    - georgemcbay 4y ago
      Looking at the docs for the library linked, it appears to be a Verhoeff algorithm check digit... so yeah, you're correct. This is effectively a simplistic stand-in for a CRC type system -- useful to detect if the data has been corrupted, but not useful to avoid collisions.
      - TedDoesntTalk 4y ago
        And if someone is worried about UUID collisions, they need to rethink their priorities in life.
    - BerislavLopac 4y ago
      You are correct, this should teach me not to write comments when I'm too tired. :/ The check digit wouldn't really help with collisions, since if the strings are the same the digit will be too. They are primarily useful when we need to ensure correctness on human input.
- throwawaymaths 4y ago
  Also most well-designed systems only use the UUID as the representation format and use raw bits in performance-critical parts.
  - lolinder 4y ago
    The raw bits are the UUID, the hex string is just a human-readable representation that also plays nicely with JSON.
    - throwawaymaths 4y ago
      Tell that to Django (well 5 years ago anyways iirc, don't know what it does now). Pretty sure it used to store uuids as strings columns in your sql.
      - lolinder 4y ago
        Yep, looks like it does the right thing in PostgreSQL but not anywhere else [0]. https://docs.djangoproject.com/en/4.1/ref/models/fields/#uuidfield https://docs.djangoproject.com/en/4.1/ref/models/fields/#uui...
        throwawaymaths 4y ago
        I feel like it did strings in postgres too, not too long ago and I had a <brain explode> moment when I worked on a codebase and had to figure out why queries were terrible
        lolinder 4y ago
        Supposedly the behavior hasn't changed since at least version 1.8: https://docs.djangoproject.com/en/1.8/ref/models/fields/#uuidfield https://docs.djangoproject.com/en/1.8/ref/models/fields/#uui... It may not have worked correctly on your project for some reason?
        4y ago
- _3u10 4y ago
  Use uint128_t instead.
- scott_w 4y ago
  The number of comments saying "using UUIDs for secrets isn't that bad" suggests this article needs to be written...
hn_user2 4y 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 4y ago
  There are KSUIDs that aim to satisfy this A go ref impl: https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid
  - scrollaway 4y ago
    Also, UUIDv6, v7 and v8. Still a draft. https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format#page-8 https://datatracker.ietf.org/doc/html/draft-peabody-dispatch...
- dexwiz 4y 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).
  - andreareina 4y ago
    They're little endian so not sortable
    - sgtnoodle 4y ago
      What does that have to do with anything?
      - andreareina 4y 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. >>> Depends on the version used. Some of them do encode time. Encoding time isn't enough, it has to be big endian (unless you write a special sorting function for uuids). Timestamped uuids store the timestamp as [timestamp_low, timestamp_mid, version(!), timestamp_high][1] which doesn't sort right. [1] https://en.m.wikipedia.org/wiki/Universally_unique_identifier https://en.m.wikipedia.org/wiki/Universally_unique_identifie...
Waterluvian 4y ago
“Moving Away From Misusing UUIDs”
Alupis 4y 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.
- withinboredom 4y 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.
  - Alupis 4y ago
    I think most languages let you chose which version of UUID you want - with most defaulting to the random version (I think 4?) by default. There are other versions that are sequential/time-based though, but using these could open the door to de-obfuscating whatever data you wanted to protect via UUID's in the first place (like how many sales orders you receive per hour, etc).
    - withinboredom 4y ago
      I don’t think uuids are designed for obfuscation, though they certainly help with that as a side effect. I could be wrong though, I’ve never looked into it.
      - Alupis 4y ago
        They (randomized type 4 UUID's) obfuscate as a side effect because they are much more difficult to guess due to their randomness. As the article points out though, they are not impossible to guess... but it will come down to your risk tolerance and what the UUID's are "protecting". People like to reach for UUID's when obfuscation is needed because inventing your own duplicate-aware random string algorithm isn't what most folks want to spend their time thinking about. Plus, these days, many databases come with UUID-aware data types that make using UUID's fairly straight forward.
dheera 4y 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 4y 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 4y ago
  UUIDs are nearly half the mac address of the server + a timestamp. They are in no way random.
  - throwanem 4y ago
    That's UUID v1. The random one that everyone uses is v4.
    - kube-system 4y ago
      I have seem some common libraries that default to v1, so I can see why there’s some confusion in here.
- nordsieck 4y 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.
  - prutschman 4y ago
    A 5 character a-z random string has log2(26^5) =~ 23.5 bits of entropy, way less than 128.
  - deleted 4y ago
    [deleted]
  - andreareina 4y ago
ilyt 4y 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 4y ago
  Depending on the UUID algorithm, some are cryptographically sufficient true random, then it would make sense..
  - ksidudwbw 4y ago
    what if you sha it?
    - WirelessGigabit 4y ago
      That actually reduces the usefulness as you're hashing the data into a smaller length.
      - unlikelymordant 4y ago
        It seems uuids are 128 bit, while sha is 160 bit. There is also sha256 and sha512 for longer hashed. So there shouldnt be any worries about the hash being shorter.
        markatto 4y ago
        Yes, some hashes might not meaningfully hurt it, but they won’t add any entropy, which is the real problem.
        jchw 4y ago
        Rereading I am guessing you're merely pointing out that the comment regarding shortening the length is untrue. If you already understand the entropy issue here, please treat my "you"s as royal you's. You have a 128 bit value. That's 128 binary digits. Each digit can be zero or one. That means you have 2^128 possible distinct values. (Ignoring the fixed bits in UUIDs since it's not important for sake of this argument.) Now you use a one-way cryptographic hash on top, like sha256. This will return a specific hash for any given input. It is always the same for a specific given input, and it is nearly always distinct. The output that a hash has may have more bits, but the number of distinct values can't increase; it can only ever decrease. That's because you could only ever give it 2^128 different values. How could it ever return more outputs if each input corresponds to one output? To make it more clear, let's say you have a database where you want to store a customer's zip code so you can use it as some kind of validation later on to ensure it matches, but you don't want to store it in plaintext, so you hash it. The hash is 160 bits. Secure, right? Wrong. There are less than 50,000 zip codes. It would be trivial to calculate the hash of every single one and use it as a simple hashmaps from hashed value to plaintext. You may be thinking this is impractical for an input domain as large as 2^128, but realistically it only adds a slight roadblock. Knowing the only valid values will be hashed UUIDs, instead of picking 160 random bits, you'd be much better off picking a random UUID, hashing it, and trying that for each attempt.
Ptchd 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
SkyPuncher 4y 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).
- tsimionescu 4y 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).

DethNinja 4y 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 4y 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 4y 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.
myaccount9786 4y 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 https://en.m.wikipedia.org/wiki/Grover%27s_algorithm Edit 2: (3:32 ET) done editing

vlmutolo 4y 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 4y ago
Not all UUID versions are monotonically increasing. This article is specifically talking about V4 UUIDs which contain random values only.

stop50 4y ago

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

postalrat 4y 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.
- BeefWellington 4y 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/ https://pypi.org/project/base-emoji/
- dspillett 4y 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 4y 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 4y 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-hackers-crypto-currency-firms-infiltrate/index.html https://edition.cnn.com/2022/07/10/politics/north-korean-hac...
- naet 4y 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?

adamrezich 4y ago

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

edflsafoiewq 4y 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 4y 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.
- vanviegen 4y ago
  How do random 128 bit IDs not fix this problem?
- dredmorbius 4y 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.)

eric4smith 4y 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.

smileysteve 4y 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.
Alupis 4y 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 4y ago
Just curious to learn: when do you need sortable primary keys?
- postalrat 4y ago
  When you need to get a sorted list or perhaps a range? When do you need primary keys?
  - endisneigh 4y ago
    that doesn't really make sense though. how would you know the range to sort by? presumably you'd use the criterion directly to sort. a better reason and justification to not use UUIDs is that they take up needless space if you're space constrained. they also have worse performance
    - 4y ago

insanitybit 4y 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 4y 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.
- insanitybit 4y 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.
  - vbezhenar 4y ago
    It’s 2^122. Or 2^128 if you don’t care about stupid standards (why would you). Birthday paradox is about getting collisions, not guessing.
    - insanitybit 4y ago
      Right, yes, guessing once specific uuid wouldn't be subject to the birthday paradox, thanks. Edited my post to no longer reflect that.

stillbourne 4y ago

I need 10^157 bit of entropy.

ComplexSystems 4y 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 4y 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 4y 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 4y ago

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

jasonwatkinspdx 4y 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 4y 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 4y ago

Some UUID alternatives: - https://github.com/ai/nanoid https://github.com/ai/nanoid - https://github.com/segmentio/ksuid https://github.com/segmentio/ksuid - https://github.com/ulid/spec https://github.com/ulid/spec

SkyPuncher 4y 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 4y 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 4y 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.)
- SkyPuncher 4y 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 4y 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.

hn_throwaway_99 4y 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 4y 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 4y ago

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

jurschreuder 4y 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.

myaccount9786 4y 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 4y 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 4y ago

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

doty 4y 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 4y 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.

smaudet 4y 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 4y 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 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 4y ago

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

daneel_w 4y 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 4y ago

There are different types of UUID that serve different purposes https://web.archive.org/web/20220623031329/https://www.ietf.org/id/draft-peabody-dispatch-new-uuid-format-03.html https://web.archive.org/web/20220623031329/https://www.ietf....

cryptos 4y ago

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

sorokod 4y ago

Few things say amateure more than calling random values pretty unique

javajosh 4y ago

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