PHP: Safe way to store decryptable passwords

Question

I'm making an application in PHP and there is a requirement that it must be possible to decrypt the passwords in order to avoid problems in the future with switching user database to different system. Consider that it's not possible to modify this future system's password method and I need plain text passwords in order to have the passwords generated.

The plan is to encrypt the user's password with a public key that is stored on the server. Authentication is done by encrypting the input and comparing the results. There is NO decryption done. The private key capable of the decryption is stored off-site for later usage.

What encryption/decryption algorithm would you suggest? Are the encrypted passwords still as safe as hashing (MD5/SHA1) when you consider the private key is not available to the attacker?

Answer 1

Part of what you are proposing is a clear violation of CWE-257. If you need to change the password storage system, then you can update the password hash when the user logs in next. Passwords should never be encrypted and then stored, they should be stored as a hash. No, md5() and sha1() are very insecure message digest functions and collisions have been intentionally generated against these algorithms. They should never be used for passwords. The use of md5() for secuirty purposes is a recognized vulnerability CWE-327.

You should use any member of the Sha2 family, sha256 is a great choice. The mhash php library has all members of the sha2 family. There is currently a competition for sha3, and this should be finalized in 2012.

Yes, all passwords should be salted with a large random value. You want to keep the salt a secret from the attacker. For instance the salt should be stored on the local hard drive so that if an attacker had sql injection to obtain the password hash, they won't have the salt. This prevents an attacker from using John The Ripper with a dictionary, instead they will have to brute force the salt separately with a password that is known to the attacker. If each password has its own salt, then it will be extremely difficult to break the salted hash.

Hashing passwords is all about delaying the attacker as much as possible.

Answer 2

Being able to decrypt the passwords is a bad idea (and there's probably not any way of doing it that would be much better than storing them unencrypted). It sounds like your main problem is being able to use the passwords if you change your storage method. Just do what Linux does, store how you're hashing the password with the password. So for example $1$salt$hash is MD5. That way, if you decide to change how passwords are stored, you can still check against the old passwords (and if someone logs in correctly, you can update their password with the new hash).

Answer 3

For most applications it is more than sufficient to store SHA-1 hashes of passwords.

Yes, there are known collisions in most hashing algorithms, but that doesn't imply an actual attack vector. Especially when you're salting the hashes.

For your salt: Store it in a configuration file that is not accessible from the outside but can be read by your PHP installation.

Answer 4

Don't decrypt the password. If you need to change the password system in the future, add a field called storage_type (or whatever).

Then, when you need to change the passwords, you will check if it's an old password. If it is, next time they login, you can change the password encoding. Otherwise, login with the new system.

Answer 5

I'll rephrase Jammer's approach -

1. Generate a public/private key pair. Hard-code the public key on your webserver. Store the private key in a physical bank locker, outside the reach of webserver/database/any developer.
2. When user registers, encrypt password + salt using public key. This step is identical to using a hash algorithm. Store the encrypted password + salt in the database.
3. When you want to verify the password, encrypt it again, and compare it to the value stored in the database.

If an attacker gets the database, he can't decrypt the passwords because he doesn't have the private key. He cannot get the private key because it is in a bank vault outside his reach. Two identical passwords will still be stored differently in the database because of the salt.

I don't recommend using the above approach because at any point of time in the future someone could abuse the private key and get access to all passwords.

But if you guarantee that the private key will always remain private, then I don't see a technical flaw.

I could be wrong, of course.

Answer 6

The only problem I see is that most public-private key encryption code out there will encrypt a symmetric key using the public key, and rely on the private key decrypting that, then use the symmetric key to encrypt the message.

You want to use the public key to directly encrypt the password+salt.

So attacks against your system boil down to:

1. Attacks against general public/private key encryption
2. Attacks against your private key store.