# Is using HMAC signature as a long-term password secure?

I'm considering implementing an authentication service without storing users' passwords/hash.

I want to use a key derivation function with a corresponding username and a master secret key to calculate the password of the user(user is actually a service). Then deliver the derived password to each user(service).

Something like using HMAC(secret_master_key, username) or PBKDF2(HMAC(secret_master_key, username)) as the long-term password for user. Or maybe some other algorithm should be more suitable for this scenario?

Is this way secure cryptographically? Thanks in advance.

• Please don't cross-post. See this meta – kelalaka Oct 15 '19 at 7:48
• @kelalaka I think this topic is more applicable here. Could I just close the topic on security site and keep this topic? – user2828102 Oct 15 '19 at 7:54
• Actually I'd recommend against deletion for now given that the comments there may still hold useful information for context. Instead you could flag your post as "recommend closure" so it will be placed into the close-vote review queue. – SEJPM Oct 15 '19 at 8:10
• FYI, an HMAC is not a signature. In cryptography, a signature is a public-key concept which is verifiable by anyone who has the public key—not just the signer who has the private key. But an HMAC, as a symmetric authenticator, is verifiable only by the parties who can create the HMAC too, and vice versa. That said, it's not the MAC property of HMAC you're after; rather, it's the PRF property. – Squeamish Ossifrage Oct 15 '19 at 13:53

As long as your master secret key is generated properly and protected properly, this should be fine. HMAC is widely believed to be a pseudorandom function. So, the output (i.e. the password = PRF(secret_master_key, username)) should be pseudorandom and has good entropy.
• If you do so, you might have to record a salt for each username if you want to regenerate the passwords. When invoking PBKDF2(password, salt, iter_count, keylength), internally PBKDF2 will invoke a PRF uses the argument password as the PRF key and a value derived from salt as the PRF input (in the first iteration, later iterations uses the previous iteration's output). The PRF can be an HMAC. If you use secret_master_key as the password argument and username as the salt argument to PBKDF2, and chooses a good HMAC (HMAC-SHA2) then it should be fine and don't need to record the salts. – Changyu Dong Oct 15 '19 at 15:18
• Make sure you make username case insensitive and encode it as an octet string before feeding it to PBKDF2. – Changyu Dong Oct 15 '19 at 15:22