0

I know that encrypting password hashes is a contentious issue. However, I have seen it recommended in some quarters. I know for instance that DropBox did this at one time with AES256. In these cases, all password hashes would be encrypted with one shared key, allowing for easy storage in a key management system (such as AWS KMS, HashiCorps Vault, or a HSM) and straightforward rotation.

However, most modern symmetric ciphers that would be appropriate for this task require random nonces. Wouldn't this mean that the nonces need to be tracked and stored somewhere?

Prime
  • 472
  • 6
  • 14

1 Answers1

2

  1. Encryption is not the right tool for this job, since there's never a need to decrypt a hash. Use HMAC(k, PH(pass)) for some password hash PH in the set of argon2, scrypt, or bcrypt. This works as a verifier as well. You can alterntaively opt to do PH(HMAC(k, pass)) instead, but this doesn't ever allow for relief protocols where the client performs the slow hashing work The former also has the nice property where clients don't ever actually have to send you a cleartext password if you so wish.

  2. If you do decide to encrypt password hashes, what's even the problem? You already have to store a salt, cost parameters, and the hash itself. What's one more thing?

Stephen Touset
  • 5,736
  • 1
  • 23
  • 38
  • 1. I have seen the HMAC approach as well - my concern there is that nesting the HMAC inside the PH provides the PH with a fixed length input, which seems non-ideal. 2. I can safely store the salt, cost parameters, and hash alongside each other in the database. Storing the nonce there as well seems inadvisable. – Prime Apr 05 '19 at 22:10
  • 2
    There's absolutely nothing wrong with having fixed-length inputs to a password hash, as long as those lengths are large enough to avoid the inputs being brute-forced. Even a 128-bit HMAC should be enough, but I see no reason to not use a 256-bit HMAC. – Stephen Touset Apr 05 '19 at 22:43
  • 4
    Why does storing a nonce alongside these other parameters seem wrong to you? It's functionally equivalent to the salt, and nonces are generally considered to be public in any cryptosystem. You are imagining threats where none exist. – Stephen Touset Apr 05 '19 at 22:43
  • If the only purpose of nonces in symmetric cryptography is to prevent replay attacks, couldn't I use a hardcoded nonce and simply store that securely as I would with the key? – Prime Apr 06 '19 at 15:39
  • That is not even the primary purpose of a nonce, much less its *only* purpose. – Stephen Touset Apr 06 '19 at 19:22
  • 1
    In the context of a symmetric cipher, nonces are used to ensure [semantic security](https://en.wikipedia.org/wiki/Semantic_security), preventing two plaintexts from encrypting to the same ciphertext even when the plaintexts are identical. Reusing nonces breaks most of the security guarantees on the tin. Fixed-length hash inputs and nonces stored alongside ciphertexts shouldn't worry you at all, but reusing nonces should *absolutely make you stop and reevaluate what you're doing*. This is how many implementors go wrong: to avoid imaginary weaknesses, they add "fixes" that introduce real ones. – Stephen Touset Apr 06 '19 at 20:12