Question

Due to our customer’s demands, user passwords must be kept in some “readable” form in order to allow accounts to be converted at a later date. Unfortunately, just saving hash values and comparing them on authentication is not an option here. Storing plain passwords in the database is not an option either of course, but using an encryption scheme like AES might be one. But in that case, the key to decrypt passwords would have to be stored on the system handling authentication and I’m not quite comfortable with that.

Hoping to get “best of both worlds”, my implementation is now using RSA asymmetric encryption to secure the passwords. Passwords are salted and encrypted using the public key. I disabled any additional, internal salting or padding mechanisms. The encrypted password will be the same every time, just like a MD5 or SHA1 hashed password would be. This way, the authentication system needs the public key, only. The private key is not required.

The private key is printed out, sealed and stored offline in the company’s safe right after it is created. But when the accounts need to be converted later, it will allow access to the passwords.

Before we deploy this solution, I’d like to hear your opinion on this scheme. Any flaws in design? Any serious drawbacks compared to the symmetric encryption? Anything else we are missing?

Thank you very much in advance!

—

Update:
In response to Jack’s arguments below, I’d like to add the relevant implementation details for our RSA-based “hashing” function:

Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
Cipher rsa = Cipher.getInstance("RSA/None/NoPadding");
rsa.init(Cipher.ENCRYPT_MODE, publicKey);
byte[] cryptRaw = rsa.doFinal(saltedPassword.getBytes());

Having quickly skimmed over the paper mentioned by Jack, I think I somewhat understand the importance of preprocessing such as OAEP. Would it be alright to extend my original question and ask if there is a way to apply the needed preprocessing and still have the function return the same output every time for each input, just as a regular hashing function would? I would accept an answer to that “bonus question” here. (Or should I make that a seperate question on SOF?)

—

Update 2:
I’m having a hard time accepting one of the present answers because I feel that none really does answer my question. But I no longer expect any more answers to come, so I’ll accept the one that I feel is most constructive.

Answer 1

I’m adding this as another answer because instead of answering the question asked (as I did in the first response) this is a workaround / alternative suggestion.

Simply put:

Use hashes BUT, whenever a user changes their password, also use your public key as follows:

• Generate a random symmetric key and use it to encrypt the timestamp, user identifier, and new password.
  • The timestamp is to ensure you don’t mess up later when trying to find the current / most up-to-date password.
  • Username so that you know which account you’re dealing with.
  • Password because it is a requirement.
• Store the encrypted text.
• Encrypt the symmetric key using your public key.
• Store the public key encrypted symmetric key with the encrypted text.
• Destroy the in-memory plaintext symmetric key, leaving only the public key encrypted key.

When you need to ‘convert’ the accounts using the current password, you use the private key and go through the password change records. For each one:

• Using the private key, decrypt the symmetric key.
• Using the symmetric key, decrypt the record.
• If you have a record for this user already, compare timestamps, and keep the password that is most recent (discarding the older).
• Lather, rinse, repeat.

(Frankly I’m probably overdoing things by encrypting the timestamp and not leaving it plaintext, but I’m paranoid and I have a thing for timestamps. Don’t get me started.)

Since you only use the public key when changing passwords, speed isn’t critical. Also, you don’t have to keep the records / files / data where the plaintext password is encrypted on the server the user uses for authentication. This data can be archived or otherwise moved off regularly, as they aren’t required for normal operations (that’s what the hash is for).