3

The "normal idea" is to generate a key per user, send them to the users (securely, of course), and store them in a database.

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? Is it secure? If not, why and how can you attack it?

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
Hehold Fehnar
  • 33
  • 2

1 Answers1

3

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

SEJPM
  • 46,697
  • 9
  • 103
  • 214