[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.

[treve]

I don't think you'll find many recommendations for key lengths under 128 bits / 16 bytes these days.

[nesarkvechnep]

Because it is?

[skrebbel]

No?