Using asymmetric encryption to secure passwords

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

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