Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
Hi @Steve, welcome to the site, and thanks for an interesting question! –  AviD Aug 10 '11 at 7:34
1  
A related question was recently asked on our sister site about cryptography: How should I store passwords that need to be available in plain text? –  Paŭlo Ebermann Aug 10 '11 at 9:50
add comment

4 Answers

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.

share|improve this answer
add comment

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 reversable encryption (not necessarly symetric as @goenfawr notes), you need at least one key (two for public key cryptography). You need to generate the key, store it securly, 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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '11 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. –  Rоry McCune Aug 10 '11 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 '11 at 21:03
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.