26

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

Improve this question
1

4 Answers 4

Reset to default
22

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.

Improve this answer
7

Is it possible to securely store passwords using reversible encryption?

Yes, but it is much more difficult and requires a much greater effort and expense. Keying is hard to do well.

In order to support the reversible encryption (not necessarily symmetric as @goenfawr notes), you need at least one key (two for public key cryptography). You need to generate the key, store it securely, protect it from corrupt or destruction, retrieve it for use, protect it while it is in use, and periodically replace it.

A significant part of the problem is how to protect the key while it is not in use. If you encrypt the key then you need another key to decrypt it. In which case you are back where you started. Other protection methods use special hardware, or secure operating systems, or even custom computers with separate memory and processors for security parameters. All these solutions require additional training and support costs.

Compare those solutions to using a retail computer, retail operating system, and a hash function.

Improve this answer
4

One thing to add to existing answers, is that it is possible to use symmetric (reversible) encryption for storing secrets (including passwords) but it's a bit more complex/expensive.

A good example of this is ATM/Cash machine networks, which traditionally used symmetric key management (although they are moving off that onto a PKI based solution).

The key (no pun intended) for this is that the encryption keys are stored in a trusted location, in this case a Hardware Security Module (HSM) and strict procedures relating to key loading and management need to be followed, to ensure that keys remain secret.

Improve this answer
3
  • 1
    The key point here, as you mention, is that there must be a delegation of trust somewhere along the way. Whether it's delegation to a database, or to a human, something in the chain must be implicitly and ultimately trusted 100%, or the solution is not secure.
    – dannysauer
    Aug 10, 2011 at 19:35
  • sure as with any solution there's a level of trust required, although I'd say that nothing can be trusted 100%, it's all relative.
    – Rory McCune
    Aug 10, 2011 at 19:42
  • And there's the crux of Security work. Some component must be 100% trusted, but it's impossible to trust anything 100%. Therefore, the job of a security professional is to understand (and communicate!) how much you can trust various components in the chain, and identify how to get the values close enough to each other. Defining "close enough" is the hard part.
    – dannysauer
    Aug 16, 2011 at 21:03
2

Have a look at the wiki page for Ciphers. Although there are many secure ciphers, there's always the risk of leaking the key. Using a one-way hash avoids this risk by not having a key.

A tenet of security engineering is to minimize the information obtainable given that the system is compromised.

Improve this answer
1
  • The cipher doesn't make a difference when the key is compromised.
    – not2savvy
    Jan 13, 2020 at 17:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .