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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Hehold Fehnar
  • 33
  • 2
  • 1
    If the user IDs are unique and you don't consider server compromise a threat / your customers aren't bothered by the fact that the server knows the secret, this looks secure. – SEJPM Feb 02 '17 at 15:52
  • The key is supposed to be shared by the server and users. Server compromise is no more threat than if a database was used. – Hehold Fehnar Feb 02 '17 at 15:57
  • Is this for session tokens (which are supposed to only have a short validity) or for password-like authentication tokens? – SEJPM Feb 02 '17 at 16:03
  • password-like auth tokens – Hehold Fehnar Feb 02 '17 at 16:04

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
  • 45,967
  • 7
  • 99
  • 205