Is it useful to protect hashed password with encryption?

Question

Imagine that I am hashing the users' passwords with a random, long enough, salt, using key stretching, and a secure hash. Would it be more secure to finally encrypt the hash with a symmetric key?

Answer 1

What's the threat model? It could be of benefit to protect the password storage with an application-side secret, but only if you think it's a realistic scenario that your database is going to get compromised—without your application server, which holds the secret, also having been compromised.

Usually, the application layer is considered the more vulnerable part and the database layer more protected, and for this reason it is not considered useful to protect the data with an application-side secret. But that may not be the case for every app, and personally I would somewhat question this assumption given the prevalence of SQL injection.

The downside of introducing an app-side secret is that you now have to worry about key management processes. What's your mechanism for replacing the key if it gets compromised? Are you going to rotate it as a matter of course? How is your key stored so that you can move servers and not lose it (potentially making all your data useless)? For short-lived keys (used for eg signing session tokens) you may not care but for long-term password storage it becomes important.

The further downside with symmetric ciphers (especially block ciphers) is implementing them correctly. Since you are hashing and don't need recoverability, you could instead include the secret in the hash (as a ‘pepper’)... but then you wouldn't be able to re-hash all the password data on a key change, so you'd have to have a multi-key method for rollover.

ETA re comment @Pacerier:

Hashing does not prevent an offline guessing attack by someone who has obtained the password database. It only increases the amount of time it takes for that attack to bear fruit; with a hashing scheme of appropriate difficulty (ie rounds of key derivation rather than raw salt length per se), it will hopefully increase that amount of time to long enough for you to notice you've been hacked and change everyone's passwords before too many of their accounts are lost.

Protecting the content with a secret key (either using encryption or including the secret key in the hashed material) does prevent the offline guessing attack, but only as long as the secret key itself is not leaked. If the secret key is on the app server separate from the database server, the passwords are only attackable if both machines are compromised.

How much of a benefit that is arguable, given that many kinds of attack can end up compromising both, especially if the app server and database server are the same machine. There also is a price to pay in manageability as discussed. So whether there is net benefit needs to be judged on a case-by-case basis with reference to the threat model.

Answer 2

I'm a big fan of adding layers of protection on top of a secure system as a part of a defense in depth policy. However, in this particular case, using symmetric encryption for this task creates another issue in the system; you'll have to take care of key management. The key must be stored somewhere, and if your application has access to it, then an attacker who compromised your system will very likely have access to the key.

Such procedure adds extra complexity to the system. Complexity is one of the enemies of security. I highly advise against it.

Answer 3

Encrypting the password-hashes can protect the passwords in a very specific situation.

There are scenarios when an attacker gains read access to your database, SQL-injection is one possibility, a leaking backup or a disposed server another. In this case, he can brute-force the password hashes. With an appropriate hash algorithm (key-derivation function), strong passwords will be safe, weak passwords though can be retrieved more or less fast with a dictionary attack (try the 1000 most used passwords...).

With encrypting your password hashes, you add a server side secret to your hashes. That means, additionally to the database, an attacker needs now privileges on the server (to get the key). This is the same advantage a pepper can give you, but it has the advantage, that you can exchange the key whenever this seems necessary.

Whether the key is stored safely is not that important, important are the additional privileges the attacker needs. In the worst case, the attacker will get the password hashes and you have the same situation as without encrytion.

Answer 4

I think there is a case for encrypting a secure digest.

It seems generally accepted that the best practice today is to use bcrypt, PBKDF2 or similar algorithms to salt and apply a work factor to the generation of the password digest. The use of a pepper is also an excellent way to mitigate poor or well known passwords from being easily brute-forced regardless of the algorithm/work factor being used.

However, the use of slow algorithms requires the work factor to be updated as hardware performance improves and it must be chosen to mitigate brute force attacks but not unduly slow password verification for users logging on to your system. By using symmetric encryption of a password hash both the work load and pepper requirements are no longer required. Provided the symmetric key is well protected (using an HSM for example) and good key management processes have been established I can't see a downside for this approach. The difficulty of a brute force attack is the same as brute forcing the key regardless of whether the password is of good quality or not.

I certainly wouldn't create the infrastructure to do this as all the previous comments regarding key management and keeping the key separate from the application server would apply. But if the infrastructure is already in place and well established there certainly are some upsides to encrypting a salted password hash.

Answer 5

I'd say no. For the reasons Adnan has said, the key needs to be accessible and this step is therefore probably just adding complexity to the system which is needless.

A better approach IMO would be to view the encryption as computing you could afford, but didn't use, and considering whether you could use that computing for a different hashing approach.

Answer 6

There is a misconception that layering different crypto practices results in something that is more secure than any individual practice on its own. However that's rarely the case.

Properly implemented password hashing with a long salt is cryptographically secure. The purpose of hashing and salting passwords is protecting the data at rest. Meaning no one that gets a hold of your password database should know what the passwords are and even if they do manage to crack one or more passwords that should not give any advantage to cracking another.

As Adobe has shown us in the past few weeks symmetric block ciphers are not great at this task. Hashing with salt avoids this problem completely.

Others have pointed out that further encrypting your hashed passwords introduces the problem of key management and offers no additional security/robustness for the stored data. Encryption is good for ensuring that only those with the proper credentials can access data. Encryption is reversible for this reason. This is not an authentication paradigm.

When we authenticate we want the server to use something that it knows (the salt) and a secret that only your user knows (the password) to consistently generate the same unique blob of data. We know that the user is who they say they are because we can reproduce this giant blob again and again. The salt ensures that even two identical passwords don't have the same hash in the database. Additional encryption offers no help on that front either.