undefined | Better HN

0 pointsAdieuToLogic5mo ago0 comments

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

0 comments

delifue5mo ago

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.

AdieuToLogicOP5mo ago

> 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/

pinkgolem5mo ago

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

javawizard5mo ago

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

1 more reply

j / k navigate · click thread line to collapse