Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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?.
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.
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.
