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

Answer 2

In terms of answering your specific question, my main concern would have been management of the private key but given it's well and truly not accessible via any computer system breach, you're pretty well covered on that front.

I'd still question the logic of not using hashes though - this sounds like a classic YAGNI. A hashing process is deterministic so even if you decided to migrate systems in the future, so long as you can still use the same algorithm, you'll get the same result. Personally, I'd pick a strong hash algorithm, use a cryptographically strong, unique salt on each account and be done with it.

Answer 3

It seems safe enough in terms of what is online but have you given full consideration to the offline storage. How easy will it be for people within your company to get access to the private key? How would you know if someone within your company had accessed the private key? How easy would it be for the private key to be destroyed (e.g. is the safe fireproof/waterproof, will the printed key become illegible over time etc).

You need to look at things such as split knowledge, dual control, tamper evident envelopes etc. As a minimum I think you need to print out two strings of data which when or'd together create the private key and then have one in your office and one in your customers office,

Answer 4

There is not enough information in the question to give any reasonable answer. Anyway since you disable padding there is a good chance that one of the attacks described in the paper "Why Textbook ElGamal and RSA Encryption are Insecure" by D. Boneh, A. Joux, and P. Nguyen is applicable.

That is just a wild guess of course. Your proposal could be susceptible to a number of other attacks.

Answer 5

One serious drawback I've not seen mentioned is the speed.

Symmetric encryption is generally much much faster than asymmetric. That's normally fine because most people account for that in their designs (SSL, for example, only uses asymmetric encryption to share the symmetric key and checking certificates). You're going to be doing asymmetric (slow) for every login, instead of cryptographic hashing (quite fast) or symmetric encryption (pretty snappy). I don't know that it will impact performance, but it could.

As a point of comparison: on my machine an AES symmetric stream cipher encryption (aes-128 cbc) yields up to 188255kB/s. That's a lot of passwords. On the same machine, the peak performance for signatures per second (probably the closest approximation to your intended operation) using DSA with a 512 bit key (no longer used to sign SSL keys) is 8916.2 operations per second. That difference is (roughly) a factor of a thousand assuming the signatures were using MD5 sized checksums. Three orders of magnitude.

This direct comparison is probably not applicable directly to your situation, but my intention was to give you an idea of the comparative algorithmic complexity.

If you have cryptographic algorithms you would prefer to use or compare and you'd like to benchmark them on your system, I suggest the 'openssl speed' command for systems that have openssl builds.

You can also probably mitigate this concern with dedicated hardware designed to accelerate public key cryptographic operations.