Recommended way of adding a pepper/secret key to password before hashing?

Question

There have been several questions regarding password hashing here and on Security.SE.

A "pepper" is sometimes mentioned – an application-specific secret key. The canonical answer on password hashing implies that a adding pepper brings the composition close to a MAC, and that cryptographic MAC function should be used rather than concatenating a pepper together with the salt and password.

My question is: Where applicable, what would be a generally recommendable, sound, well understood way to MAC a user password and a secret key, in the context of password hashing?

I want to MAC the password using a secret key, then feed the output of the MAC to a slow hash function (like bcrypt, scrypt, or PBKDF2). I want to know what kind of MAC to use. To represent the MAC, I'm using this notation

• HMAC-SHA256_secretkey(message) and HKDF_salt(password)
• password is the low-entropy user password
• key is the high entropy secret key (the "pepper")
• salt is a per-password random value, optionally reused by the subsequent computationally expensive hash such as bcrypt, PBKDF2, or scrypt

Would any of these constructs be more recommendable? Or is there an even better way? And if so, briefly why?

1. HMAC-SHA256 _key(password)
2. HMAC-SHA256_password(key)
3. HKDF_password(salt)

NB: This question is in relation to the "pepper" section near the end of the accepted answer to "How to securely hash passwords". Thus the output of the MAC will be fed to a slow, computationally expensive KDF like bcrypt, PBKDF2, or scrypt.

Answer 1

Given the clarified answer, I suggest you do the following:

$T = F_k(\text{password})$

$Y = H(T, \text{salt})$

where $F$ is a PRF (pseudorandom function) and $H$ is a slow hash. Here $k$ is the secret key (the "pepper").

You can instantiate $F$ with AES-CMAC or SHA256-HMAC (or any other good PRF). When you use $F$, feed the secret key $k$ (the pepper) into the key input of the PRF, and feed the password into the message input for the PRF. (This corresponds to your option 1. I do not recommend using your option 2, and definitely not option 3.)

You can instantiate $H$ with a slow hash like bcrypt, scrypt, or PBKDF2. When you use $H$, feed $T$ into the password input for the slow hash, and feed the salt into the salt input for the slow hash.

Finally, store $Y$ and the salt in your database of hashed passwords.

This scheme ensures that if the key $k$ (the "pepper") is kept secret and is not known to the adversary, then the adversary will not be able to recover any of the passwords. It also ensures that if the key $k$ does become known to the adversary, the best the adversary can do is a dictionary attack on the passwords -- but this will be slowed down because of the slow hash. Consequently, if $k$ does become known to the adversary, this scheme should be no worse than just using scrypt/bcrypt/PBKDF2 without a pepper.