Primary keys using UUID v7 are potentially an HR violation | Hacker News Reader

Primary keys using UUID v7 are potentially an HR violation

mikenotthepope.com

Job history, education history, actual date of birth capture, military service etc are all other parts of applying for a job generally speaking and can also determine if someone is "old" ... as an older guy, I myself have seen a lot of shift the closer I got to my current age of 50yo.

UUIDv7 isn't exactly the compromise it's made out to be in the current context.

I suppose you can infer, very roughly, that a UUID with an older date stamp inside it is possessed by an older user ... very roughly.

At the same time age of account is all over forums and other places, often used to demonstrate a certain level of trust vs say new accounts.

Is that also a privacy issue? I'm not sure I like the implications if it is.

Practically speaking, an applicant's resume/CV will say more about their age than a UUID v7. I think the risk of someone's minimum age being leaked is low, but it's not zero, so I went with UUID v4. Mostly I just thought it was interesting, so I shared :)

The encryption implementation suggested seems overkill and problematic as it increases the size of the ID. UUID is 128 bit which is the same block size as AES. You can simply apply AES to transform the input block with a secret key to and directly expose the result. No need for CBC mode or IVs etc as it is desirable for the same input to map to the same output all the time.

Now you have a secret key that must live in every web server yet can never be rotated.

That's a different kind of maintenance nightmare.

That limitation is present in the CBC mode solution presented as well. A random IV will not help you avoid "key rotation" if that's a design requirement. By design, you won't want to rotate the key as the encrypted UUID will likely be stored in external places to refer to the specific user and it cannot change unless you basically persist the encrypted ID somewhere, in which case you might as well have two IDs, one completely random.

The solution is to use hash function. It is fine to cut down hash output so 128-bit from SHA-1 would be fine.

How would you look up the key if it is passed it back to you from another API? It won't be reversible.

If you want to persist two keys, you might as well generate a random second key and persist that. No crypto shenanigans needed.

If this is well-known, won't applicants create new accounts instead of ever using the old ones? Like unsold houses, if they're on the market too long, the listing will be removed and a new one will be created instead of dropping the price to maintain that illusion of a new listing.

External IDs shouldn't contain any metadata, UUIDv4 should be used for those. UUIDv7 is suitable for database primary keys when simple incremental IDs are not sufficient, but primary keys should really never be used externally.

For some things there's no obvious unique identifier other than a something random. Out of curiosity, do you maintain separate IDs, one internal and one external?

Yea, I usually keep a simple incremental ID or whatever is default for internal IDs, and a separate external ID for entities that are presented externally. For security and not unnecessarily leaking info about the number of records, time and rate of record creation etc. UUIDv4 is convenient for uniqueness, but impractical if the ID needs to be conveyed over phone or written down – or used in URLs, so I often use some system for slugs or short codes in addition to the UUID.

Don't expose primary keys to the public. Create separate external ids instead. I personally use BIGINT primary keys, with UUIDv4 external ids, but any random string will do.

Plus, it’s easy to tell v4 from v7, if internally you have no choice on keys.

Certainly seems the easiest solution. A lot of handwringing about poor database performance of UUID4 when you could use it exclusively for an external identifier all for the cost of an additional column.

Also, poor performance of UUIDv4 primary keys is most related to how write heavy your table is in the first place, and in particular how insertion heavy it is. In theory your users table shouldn't be very write-heavy, even if it may be insertion-heavy compared to other writes.

Reply on news.ycombinator.com