3
$\begingroup$

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?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ 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. $\endgroup$
    – SEJPM
    Commented Feb 2, 2017 at 15:52
  • $\begingroup$ The key is supposed to be shared by the server and users. Server compromise is no more threat than if a database was used. $\endgroup$
    – Hehold Fehnar
    Commented Feb 2, 2017 at 15:57
  • $\begingroup$ Is this for session tokens (which are supposed to only have a short validity) or for password-like authentication tokens? $\endgroup$
    – SEJPM
    Commented Feb 2, 2017 at 16:03
  • $\begingroup$ password-like auth tokens $\endgroup$
    – Hehold Fehnar
    Commented Feb 2, 2017 at 16:04

1 Answer 1

Reset to default
3
$\begingroup$

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

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.