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);
  1. 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.

  2. 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.

  3. 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.

  4. 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.
  • 1)I read here, and it looks reasonable, that adding pepper like this will significantly reduce security as it reduces salt’s randomness – BbIKTOP Aug 11 '20 at 13:11
  • 1
    That's just plain stupid. How does it reduce the salt's randomness? Please provide a citation, that should be an interesting read. – A. Hersean Aug 11 '20 at 13:12
  • 1
    You can technically encrypt a hash, and I wrote how to do it better than what you suggested. I would not recommend it however. In cryptography, when choosing among two functionally equivalent schemes, you should always favor the simpler. Apply the KISS programming principle: "keep it simple stupid". – A. Hersean Aug 11 '20 at 13:18
  • 1
    "Mostly because you apparently", - could you please explain it not discussing my personal abilities, but in relation to the described use case? – BbIKTOP Aug 11 '20 at 13:23
  • 1
    I'm sorry if I hurt you you with my comment. I still advise caution. RSA should not be used here, for far too many reasons that would distract from the main point of my answer, and I will not detail it further here. If you want more information on this specific topic, please submit a second question. – A. Hersean Aug 11 '20 at 13:30

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.