[AdieuToLogic]

>>> Using UUIDv7 is generally discouraged for security when the primary key is exposed to end users in external-facing applications or APIs.

>> So this basically defeats the entire performance improvement of UUIDv7. Because anything coming from the user will need to look up a UUIDv4, which means every new row needs to create an extra random UUIDv4 which gets inserted into a second B-tree index, which recreates the very performance problem UUIDv7 is supposedly solving.

> This is only really true if leaking the creation time of the record is itself a security concern.

No, as "leaking the creation time" is not a concern when API's return resources having properties representing creation/modification timestamps.

Where exposing predictable identifiers creates a security risk, such as exposing UUIDv7 or serial[0] types used as database primary keys, is it enables attackers to be able to synthesize identifiers which match arbitrary resources much quicker than when random identifiers are employed.

0 - https://www.postgresql.org/docs/current/datatype-numeric.htm...

[delifue]

With proper data permission check, having predictable ID is totally fine. And UUIDv7's random part is large enough so that it's much harder to predict than auto increment id.

If your security relies on attacker don't know your ID (you don't do proper data permission check), your security is flawed.

[AdieuToLogic]

> With proper data permission check, having predictable ID is totally fine.

That qualification is doing a lot of work in this sentence. For supporting evidence as to why this is the case, a quick search for "CVE PHP security vulnerabilities" or "CVE NodeJS security vulnerabilities" will produce voluminous results.

> And UUIDv7's random part is large enough so that it's much harder to predict than auto increment id.

Usually. One common scenario where using UUIDv7 for primary keys in a persistent store can be exploited similar to sequential integer ID's is when there are queries supporting pagenation and/or those leveraging the temporal ordering UUIDv7 supports intrinsically. For example:

  id > aSynthesizedUUIDv7Value

Note that this does not require successful identification of either the `rand_a` or `rand_b` UUIDv7 fields[0].

> If your security relies on attacker don't know your ID (you don't do proper data permission check), your security is flawed.

Again, I agree with this in theory. But as the saying[1] goes:

  In Theory There Is No Difference Between Theory and 
  Practice, While In Practice There Is

0 - https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-versio...

1 - https://quoteinvestigator.com/2018/04/14/theory/

[pinkgolem]

Is that not quit commen for invites/no user account shares?

[javawizard]

Indeed, but one could easily argue that 128 bits of entropy aren't sufficient for a good invite token in the first place.

[pinkgolem]

I am just puzzled why delifue calls something that, as far as I know is pretty standard across the industrie, bad practice

[treve]

There's 2 cases being discussed. A UUIDv7 is a bad secret, but it's fine for many other ids. If I can guess your user id, it shouldn't really matter because your business logic should prevent me from doing anything with that information. If I can guess your password reset token it's a different story because I don't need anything else beyond that token to do damage.

[tracker1]

But the random part of a UUIDv7 is 74 bits... larger than a 64-bit integer of random values. Larger than many systems use in total when generating random keys for such things. Likely a larger number of values than the total number of comments here on HN over a couple decades. It's emphatically NOT guessable.

[nesarkvechnep]

Because it is?

[skrebbel]

No?