But what if I use a keyed hash (like Blake2b) with a server key and
then hash the user ID to generate the user key to avoid the need to
hold a database of randomly generated keys?
Let's make some assumptions: the user IDs are unique and Blake2b with a keyed input acts like a PRF and you supply a long-enough key, all of which are reasonable. Then for any given (userID,hash) pair you can't learn anything about the other pairs (if you're computationally bounded).
There are a couple of potential issues with this though:
- The user can't choose their credentials themselves, users may dislike this.
- It is potentially easier to exfiltrate a short secret than a large amount of data (like in a database).
- You must ensure that the userID is always given in the exact same encoding to the hash function.
- If the credential gets compromised on the user end, the user also has to change the userID or you have to change the master key
- Key roll-over gets harder as every client needs to log-in to receive their updated access token
There's an upside to this sort of scheme though: If you want to, you can put the secret inside a HSM and use HMAC-SHA256 instead of Blake2b and mitigate the key exfiltration risk