6

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.

Community
  • 1
Stephen Touset
  • 5,774
  • 1
  • 23
  • 38
  • 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

1 Answers1

7

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.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 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
  • In hindsight, HMACing the password *before* applying a password hash comes with all the advantages of a MAC (simplicity, strong conceptual alignment) with none of the disadvantages. Were I to make this decision again today, I would go that route. – Stephen Touset Aug 22 '14 at 21:01