Is encrypting the password hash in database more secure than storing only the hash?

Suppose we store encrypted SHA-256 result with AES instead of hash directly. Is this a good protection from a situation in the future when someone will break one of the algorithms?

  • It doesn't hurt anything but it doesn't help anything either. – Andrew Hoffman Nov 25 '14 at 19:02

First of all, every stored password should be hashed with a different pseudo-random salt. Second, SHA-256 is not appropriate for storing passwords; instead, you want to use a key stretching algorithm, as has already been mentioned. There is a lot more detail at Crackstation.

An encrypted hash is also called a keyed hash, and the key is sometimes called a "pepper." There need not be a separate encryption step. Instead, the secret key is part of the input to the hash function. That can improve security somewhat. There are two ways attackers can get a copy of your password hashes. One is to compromise the storage mechanism, as with SQL injection. In that case, a keyed hash can make it effectively impossible to retrieve plaintext passwords from the hashes because the key can be compiled in to a program or otherwise kept outside the password storage mechanism. The other way is to compromise the OS itself. In that case, the key is compromised, and is no longer an impediment against attempts to attack the passwords.

So, the short answer is yes, but you have to do the underlying work right, first.

| improve this answer | |
  • IMO encrypting the hash is superior to a pepper/secret salt. Security wise they're the same, but a key can be changed (simply decrypt and re-encrypt the data) and it integrates better with a HSM. – CodesInChaos Nov 25 '14 at 15:26

Provided that you mean Hash first (BCrypt) and then encrypt the hash, security should not be weakened, yet you are not improving security either.
Encryption is, by definition, a reversible scheme. Since there really is no use-case for which you would require the decryption in this case, encryption is the wrong tool for the job.

If you are looking use a 'secret key' in combination with password hashing, your should make use of an HMAC instead (commonly refered to as 'using salt & pepper'). For more information on HMAC and Hash see: Password Hashing add salt + pepper or is salt enough?. For a discussion on how to implement this, see: How to apply a pepper correctly to bcrypt?.

| improve this answer | |
  • 1
    I think you're missing a "not" in your first sentence. – Mark Nov 25 '14 at 11:19
  • I thought I disagreed with your premise that security isn't or can't be improved, but I think I was just misreading as the first sentence isn't entirely clear. If you mean that security isn't improved compared to bare hashing, it demonstrable can be, but if, as I now believe, you mean that it isn't more secure than a keyed hash, I can agree with that. – Xander Nov 25 '14 at 14:49
  • @Xander, My English is not native, so maybe I should not write answers as they may be confusing. What I mean is that encryption, in case that no decrypt is ever needed, is the wrong tool for the job and that an HMAC would be better suited. – Monika Nov 25 '14 at 15:34
  • Ok, that makes sense, and thank you for the clarification! – Xander Nov 25 '14 at 15:42

Bob Brown has covered most of the salient points in his answer but I did want to point out that there is one significant disadvantage: Complexity. You are increasing the complexity of your application to some degree, lesser (in the case of adding a pepper to the hash where you need to think about key management as well as storage of password hashes and salts) or greater (in the case of implementing something more sophisticated like AES and needing to store IVs or Nonces and possibly tags/MACs as well as the output, the salt, and managing the key(s).)

So, is the value you're going to add sufficient to justify the additional cost of complexity? You'll have to answer that question for your application. I'd would say that it generally doesn't, while there certainly are cases out there where it does.

In any case, as Bob mentioned, you need to start with a strong foundation and move to a better hashing algorithm like Bcrypt regardless of whether you decide to encrypt or not.

| improve this answer | |

If you encrypted the hashed+salted password it means that it can be decrypted. The key management (as usual) is a hard to solve problem. If this hashed password can be decrypted this may apparently stand as a better security posture (as of not encrypting it), but in reality it may introduce a vulnerability, which is the key management, without really upgrading the security for the password.

A better idea may be to hash multiple times and store the final version.

The idea of using hashes to store passwords is to block the option of going back to a clear text password, if you introduce encryption (not hashing) in the process, you are going in the opposite direction. I understand you are working with the hashed password, not a clear text password, but it may be not as good as incrementing the hashing iterations.

| improve this answer | |

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.