Pitfalls of encrypting (with salt) of a md5-hashed-password (php)

Question

A client has a huge userbase and I'm required to encrypt/hash passwords in a secure manner. The problem is I can't ask every user to change their password and the passwords are already hashed with md5() without a salt. One way of doing this is to encrypt the current passwords with a salt and when a user changes or resets the password i just encrypt it with the salt.

Are there any pitfalls or more or less obvious dangers of doing so [ i mean sha1(md5(password) with salt) ]?

Thank you for your time

Answer 1

if you plan to use sha1(md5(password).$salt) it's all right.
You can use this system even further. No need to take any special action when user changes a password. Just encrypt it the same way: sha1(md5(new password).$salt)

Answer 2

If the md5 collides, the sha1 will collide too. (Because you are encrypting the same md5 with the sha1)

You should use only sha1, and have a field in your database that determines if the user is using the old or new password algorithm.

When the user enter his password and it is correct, you'll have the password, just update the password field to the new algorithm.

Answer 3

Add a new field to the user table for storing the new securely hashed passwords - for this, please do something safe involving per-user salt and multiple rounds. Check what other people are doing (ie., bcrypt) instead of rolling your own.

When doing a password check, if the newPass field is null, use the old password lookup, but urge users to do a password reset once authenticated.

Modifying the current (old) password scheme to be hash(perUserSalt + existingPassWordHash) should work fine.

Answer 4

It depends on what attack you are attempting to defend against. If the attack is someone viewing the database, then you could use a symmetric encryption method (like AES) with a key defined outside the database. Using this method requires the authentication procedure know the encryption key and you update all the rows in the database by encrypting the hashed password with the encryption key.

If the above is not an option, you have a problem. ;) The problem is that right now you don't know what any user's password actually is. All you have is the hashed version. Your routine for verifying a login is to take the input supplied by the user, hash it, and compare the computed hash with the stored hash.

Your option would be to store the old hash and create a new field to store the new algorithm. Then as people log into the system, perform the upgraded salted-hash and delete the old hash. This will work as you expect, but if a person never logs back in (or changes their password) they will never upgrade to the salted version of the hash.

My personal opinion is to use the AES encrypted option since that prevents the casual viewing of hashed passwords and it covers all the passwords in the database.