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 '12 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. – Stephen Touset Aug 24 '12 at 21:17

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. – Stephen Touset Aug 24 '12 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. – Thomas Pornin Aug 24 '12 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. – Stephen Touset Aug 24 '12 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. – Thomas Pornin Aug 25 '12 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. – Stephen Touset Sep 26 '12 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.