Is it possible to securely store passwords using reversible encryption?
Everyone says that you need to use a non-reversible hash when you store passwords so that even if your database is leaked, the passwords themselves are still safe. I'm wondering if there is any way to use reversible encryption to store passwords.
At the very least, you would need to require that any exploit that leaks the database (SQL injection, server shell access, etc.) doesn't leak the encryption key and that it would not reasonably be possible to figure out the encryption key using a known plaintext password if you have the leaked database.
I'm not seriously considering doing this because it seems like even if it's technically possible it would be hard to do correctly, but it seems like an interesting problem.
Reversible encryption is not commonly used for passwords because the specific requirements and parameters of password authentication are incompatible with the weakness of reversible encryption.
The primary weakness of reversible encryption is simple: if the key is compromised, the encrypted data is compromised, period. Passwords are used all the time, whenever users log in. Therefore, the authenticating process must be able to access the users' credentials all the time, in an automated fashion, without obstructive controls. That means that the key for reversible encryption needs to be on disk or in memory all the time. If that program, disk, or memory are somehow compromised, then all those reversibly encrypted passwords are all compromised in one fell swoop.
In contrast, consider the use of non-reversible hashes. If the program, disk, or memory are compromised then the attacker gets the "locked" hashes, and there is no key. They can then attack further - known ciphertext attack, brute force, etc - but they haven't "won" yet.
We do use reversible (let me say keyed) encryption all the time - disks, files, email attachments. What these uses all have in common, though, is that they encourage (if not require) human intervention to provide the key. I'm not sure why you're asking about this, but what about a hybrid model? Consider that it might be reasonable to store both reversible and non-reversible ciphertext for user passwords. When passwords are created, store two enciphered versions: One created with a one-way hashing function, and the other created with an asymmetric encryption algorithm ("public key cryptography"). All automated authentication processes use the non-reversible hashes for authentication purposes. Keep the "public key" half of the pair on the system for use generating the enciphered passwords, and store the "private key" half of the pair offline. In the event the password plaintext is needed, take the encrypted password offline and decrypt it with the appropriate key. As long as the decrypting key is not accessible to the authentication system, then an attacker cannot take advantage of the fact that you used "reversible" encryption to store plaintext passwords. That'll only help if your need for accessing the plaintext passwords is not an automated need, of course. But it seems like a nifty idea to me.