4 ms·

They're to be generated for each individual UUID. (However, this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a securi

They're to be generated for each individual UUID. (However, this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a security-related context, presumably with a CSPRNG.)

hn_throwaway_99 5y ago
Thanks. To be honest then, that last bit, "this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a security-related context, presumably with a CSPRNG." makes me think this RFC could cause some problems. v6 UUIDs only have 48 bits of randomness, which means that some newbies will think that's "good enough" for security, when in reality it's not. I still like these new UUID types because I would use them as DB primary keys now (benefit of being time sorted but also globally unique and offers some protection against IDOR bugs), but important to know where not to use them.
- pjscott 5y ago
  Yeah, I'm a bit torn on this security-wise. On the one hand, their only real security-relevant ambition here is to avoid leaking MAC address info, a classic UUID foot-gun, and they do achieve this. Probably a much better set of defaults! On the other hand, yeah, the mere presence of some random bits could lull people into a false sense of safety, especially as the RFC doesn't say anything about where those bits should come from except that it should have enough entropy to make collisions minimal. On the third hand, anybody who thinks that 48 random bits of unspecified provenance are enough for a secure token was probably always going to mess up somehow, so I'm not sure how much difference this makes on the margin.
- aidos 5y ago
  They’re perfect for client generation of db ids. I was looking to do exactly this format, but decided not to do anything that was weirdly non-standard. Uuid6 is the one I’ll be switching to now.
- staticassertion 5y ago
  I feel like understanding the guarantees is really simple. A value can be unique while still being guessable, and that's the idea with this latest revision. If you want something to be unique and unguessable, that's another uuid (or just use random bits, there's no benefit to a uuid here, generally).
  - zaphirplane 5y ago
    UUID are better than random for distributed ID generation, I though
    - staticassertion 5y ago
      Nope, v4 are just random with a version tag.

hn_throwaway_99 5y ago

Thanks. To be honest then, that last bit, "this RFC recommends using the entirely random UUID4 for anything that's meant to be used in a security-related context, presumably with a CSPRNG." makes me think this RFC could cause some problems. v6 UUIDs only have 48 bits of randomness, which means that some newbies will think that's "good enough" for security, when in reality it's not. I still like these new UUID types because I would use them as DB primary keys now (benefit of being time sorted but also globally unique and offers some protection against IDOR bugs), but important to know where not to use them.

pjscott 5y ago
Yeah, I'm a bit torn on this security-wise. On the one hand, their only real security-relevant ambition here is to avoid leaking MAC address info, a classic UUID foot-gun, and they do achieve this. Probably a much better set of defaults! On the other hand, yeah, the mere presence of some random bits could lull people into a false sense of safety, especially as the RFC doesn't say anything about where those bits should come from except that it should have enough entropy to make collisions minimal. On the third hand, anybody who thinks that 48 random bits of unspecified provenance are enough for a secure token was probably always going to mess up somehow, so I'm not sure how much difference this makes on the margin.
aidos 5y ago
They’re perfect for client generation of db ids. I was looking to do exactly this format, but decided not to do anything that was weirdly non-standard. Uuid6 is the one I’ll be switching to now.
staticassertion 5y ago
I feel like understanding the guarantees is really simple. A value can be unique while still being guessable, and that's the idea with this latest revision. If you want something to be unique and unguessable, that's another uuid (or just use random bits, there's no benefit to a uuid here, generally).
- zaphirplane 5y ago
  UUID are better than random for distributed ID generation, I though
  - staticassertion 5y ago
    Nope, v4 are just random with a version tag.