It's based on SHA-1, which I understand to be no longer recommended as a hashing algorithm.
You can mitigate this by first hashing your composite key with a stronger algorithm (such as SHA 512), and then use the hash as input to the UUID v5 algorithm.
It seems to require one part of the input to be a UUID, but neither part of the composite key is.
To create a v5 UUID you need a namespace and a name. The namespace is indeed another UUID. It's purpose is to ensure global uniqueness - as long as my namespace is globally unique, it does not matter if my names are not. A common way to pick a namespace is to just generate a random v4 UUID once, and then use it whenever you generate UUIDs for this specific purpose.
The next obvious choice would be to use a SHA-256 hash and "compress" it into 128 bits. [...] Is it bad practice to use all 128 bits of a UUID instead of using the reserved bits for variant and version?
You can do this, sure, but it would not result in an UUID. If the reserved bits are not valid or, even worse, are incorrecct, you do not have an UUID as per the specification. Sure, you have a 128 bit digest, but it is not an UUID. Do not expect it to work in systems expecting an UUID.
To do this and call it an UUID would be bad practice. And actually, there is no need to. You can just use a v5 UUID:
- As a namespace, consistently use the same random v4 UUID.
- As a name, use a SHA 512 hash of the composite key. (You can use all bits, no need to truncate it, since the name can have any length.)
n/2Input bits for a hadh function with
noutput bits to prevent collisions
Strings. Isn't @dandavis right though? With a good hash function isn't the risk of collision on 128 bits minuscule (the point of UUIDs)?
Strings to a
UUIDyou'll have to worry about collisions. Its very likely that you wont get collisions because you have too few users; but from a pure mathematical perspective collisions are an issue if you could have enough users to get collisions.