4 ms·

Just a heads up about UUID 7.. be careful when using. par the RFC If UUIDs are required for use with any security operation within an application context in a

Just a heads up about UUID 7.. be careful when using. par the RFC If UUIDs are required for use with any security operation within an application context in any shape or form then [RFC4122] UUIDv4 SHOULD be utilized.

spoiler 2y ago
I was thinking of adopting UUIDv7 for some of my stuff. So, I'm curious: why is this the case? Is it because of the time component?
- vbezhenar 2y ago
  1. UUIDv7 allows to extract timestamp 2. UUIDv7 allows to predict first half, if you know the timestamp. 3. UUIDv7 provides 62 bits of randomness compared to 122 bits for UUIDv4. Whether that's a problem for your particular use-case or not, it's up for you to decide. I don't think that UUIDv7 is "insecure", it just provides different trade-offs and in some situations it might be less secure compared to UUIDv4, but I hardly see any attack vector where you could issue 2^62 requests to brute-force the ID.
- lulzury 2y ago
  That's what the RFC states: > Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with an embedded counter does signal the order of creation for a given UUID and its corresponding data but does not define anything about the data itself or the application as a whole. If UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 (Section 5.4) SHOULD be utilized. https://datatracker.ietf.org/doc/html/rfc9562#name-security-considerations https://datatracker.ietf.org/doc/html/rfc9562#name-security-...
- deleted 2y ago
  [deleted]
jandrewrogers 2y ago
Unfortunately, UUIDv4 is often specifically prohibited for some sensitive applications due to many cases of broken RNGs undermining the security guarantees of UUIDv4. Deterministic generation plus encryption is a common choice in these cases.
- jrochkind1 2y ago
  The important point is that UUIDv7 is even worse (and unsuitable) for that application so anything prohibited UUIDv4 for those reasons would not be okay with v7 either!

spoiler 2y ago

I was thinking of adopting UUIDv7 for some of my stuff. So, I'm curious: why is this the case? Is it because of the time component?

vbezhenar 2y ago
1. UUIDv7 allows to extract timestamp 2. UUIDv7 allows to predict first half, if you know the timestamp. 3. UUIDv7 provides 62 bits of randomness compared to 122 bits for UUIDv4. Whether that's a problem for your particular use-case or not, it's up for you to decide. I don't think that UUIDv7 is "insecure", it just provides different trade-offs and in some situations it might be less secure compared to UUIDv4, but I hardly see any attack vector where you could issue 2^62 requests to brute-force the ID.
lulzury 2y ago
That's what the RFC states: > Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with an embedded counter does signal the order of creation for a given UUID and its corresponding data but does not define anything about the data itself or the application as a whole. If UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 (Section 5.4) SHOULD be utilized. https://datatracker.ietf.org/doc/html/rfc9562#name-security-considerations https://datatracker.ietf.org/doc/html/rfc9562#name-security-...
deleted 2y ago
[deleted]

jandrewrogers 2y ago

Unfortunately, UUIDv4 is often specifically prohibited for some sensitive applications due to many cases of broken RNGs undermining the security guarantees of UUIDv4. Deterministic generation plus encryption is a common choice in these cases.

jrochkind1 2y ago
The important point is that UUIDv7 is even worse (and unsuitable) for that application so anything prohibited UUIDv4 for those reasons would not be okay with v7 either!