Encrypting salted password hash before storing in the database

Question

I have read here and here, that instead of using pepper, it is better to encrypt hashed/salted passwords before storing in the database. Especially with Java, as there's no library for salt/pepper, but just for salt hashing, and I'm not going to implement my own crypto in any way. Have questions about it:

1. Is it true? Will it add security, if db server is on another physical computer, and encryption keys are stored on the app server's fs?
2. If so, is it ok to use RSA for hash encryption?
3. To check password in this case, is it better to read encrypted password from the DB, decrypt it, and then compare it to the hashed/salted one entered by user, or encrypt entered hashed/salted password and then compare with the encrypted value in the database? In this case, will it be the same as using another hash, as encrypted hash is never decrypted?

A code sample that I use to get hash now:

KeySpec ks = new PBEKeySpec(password, salt, 10, 512);
SecretKeyFactory kf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA512");
SecretKey sk = kf.generateSecret(ks);

byte[] hash = sk.getEncoded();

A code I am going to add:

Cipher cipher=Cipher.getInstance("RSA");
cipher.init(Cipher.ENCRYPT_MODE, privateKey);
byte [] encryptedHash=cipher.doFinal(hash);

Answer 1

0. Encrypting a hashed password is not better than adding pepper, despite what you read in your cited answer. It is functionally equivalent, but more computationally intensive (wasteful) and it increases the chances to introduce bugs.

1. You do not need a special library to add pepper. Since you have a library that handles salt, you just have to replace the code hashPassword(thePassword, theSalt) by hashPassword(thePassword, the128bitRandomPepper + theSalt). With + being the string concatenation operator in Java.

2. RSA is an asymmetric encryption algorithm. This is not at all suited in this context. Just do not encrypt. But if you really need to, use AES-GCM (for those wondering why GCM: it's mainly to force the OP to correctly handle the IV). Then post your full scheme here to have it reviewed, because you might still do mistakes.

3. Just do not encrypt, instead use your library as described in point 1.

To answer the claims made in the two links you cite:

• From stackoverflow and from security.SE: One can rotate the encryption keys. However, once the database is breached, that is useless: either the encryption is good, and changing the passwords or rotating the key is useless; or the encryption is weak and the passwords need to be changed.
• From stackoverflow: Encryption is more secure than hashing. That's wrong.
• From stackoverflow "since he knows the salt and the output, he can brute force the pepper" The same applies with encryption. This is not an issue with a pepper handled as a key.