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.

Improve this question
2
  • 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.
    – Stephen Touset
    Aug 24, 2012 at 21:17

1 Answer 1

Reset to default
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.

Improve this answer
6
  • 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, 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.
    – Thomas Pornin
    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.
    – Stephen Touset
    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.
    – Thomas Pornin
    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.
    – Stephen Touset
    Sep 26, 2012 at 17:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .