Assume I am hashing user passwords with PBKDF2, bcrypt, scrypt, or some other secure key derivation function.

Are there:

  1. tangible security benefits,
  2. precedents, and
  3. respected research

for protecting these hashes from offline attacks by either encrypting the hashes or otherwise applying a secret key to them via, say, an HMAC?

I believe this previous post attempted to ask a similar question, but the question was unclear and treated by most responders as if it asked whether or not passwords themselves should be HMACed instead of being passed through a salted KDF first.

  • encryption does not provide authentication. This question is erratic.
    – rook
    Aug 24, 2012 at 19:19
  • 1
    With all due respect, my question was not about authentication, but about protecting verifiers from offline attacks (e.g., the salt/password database being leaked). I understand that creating your own homemade constructs based upon secure cryptographic primitives can weaken or entirely defeat security through unintended and unintuitive means. Hence I further asked if there was precedent and/or research supporting this type of approach. Aug 24, 2012 at 21:17

1 Answer 1


Encryption, or a deterministic MAC, may offer you an extra gain of security on the off-chance that the attacker could grab the database of hashed-and-encrypted passwords but not the encryption/MAC key (which the same server must necessarily know to do his job). Some people call that "pepper" (as a pun with the notion of "salt" -- IT security people are a bunch of joyous fellows). See this previous question on the subject.

Since the scenario is rather restrictive, and using a key implies dealing with key management issues, I would recommend not to bother.

  • I wouldn't necessarily say it's an off-chance. And even with key management issues, is there any reason to believe that an additional HMAC step would decrease security? Even assuming the worst-case scenario of your key becoming publicly exposed. Aug 24, 2012 at 18:34
  • HMAC with a non pathological hash function (i.e. HMAC with SHA-256, SHA-1 or even MD5) should not decrease the security of a password-hashing scheme. Aug 24, 2012 at 18:40
  • Out of curiosity, is there any particular advantage to an HMAC versus encryption versus including a pepper when hashing the password and salt (ignoring for a moment that PKBDF2, bcrypt, and scrypt have no formal pepper parameter, which would lead me to discourage that approach). My intuition is that an HMAC is a better choice here. Aug 24, 2012 at 22:52
  • HMAC is hard to get wrong: no randomness, simple API, already implemented in various frameworks. That is a very strong reason to prefer HMAC. Aug 25, 2012 at 21:37
  • 1
    If you're interested to know, I ended up going with an AEAD mode of AES rather than HMAC. The rationale being that bcrypt digests canonically contain the algorithm version, salt, and digest in a single string. That information would be lost if HMAC'd, making it impossible to actually verify a password against it. Thus, I chose reversible encryption rather than having to deal with splitting out the pieces and reassembling them later. Sep 26, 2012 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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