In PHP, what would be the best way to migrate MD5 encrypted data to SHA?

As Karim has indicated, a hashing function is a one-way operation.  You cannot go backwards in order to then compute a different hash. If you have stored an MD5 password hash and you'd like to convert to a SHA hash, then the only way I know of to do that is to wait until the user next enters their password and if it verifies with the MD5 hash, you calculate the SHA hash, store that as the new hash and mark that you've already converted it to SHA so you know which type of hash to compare to in the future and so that you know that it's already been upgraded to SHA.

an Hash is a codified piece of fragmented data. By nature the Hash does not contain any of the source data so you can't reverse it..... it theory Two methods : 1 - Ethical approach : Asking users to input again their password at next login 2 - Not so Ethical approach : you can crack the MD5 hashes in order to retrieve the plain passwords (of course we talk about string passwords). The second method can take a lot of time and need dictionaries in order to speed up things (depends on the passwords complexity and length). You'll have to build a file dump of your passwords. And a good computer : A 10 random caracter password with special caracters takes more than a week to be found in an intel dual core 2.8Ghz. You must notice your users of such procedure if you had to reveal their passwords. If the second method use is not forbidden by your company or by the laws that protects the users data then you'll try to use a program that has the name of a legendary english criminal. http://en.wikipedia.org/wiki/Password_cracking Keep in mind that MD5 has a collision probability witch means that the password you find is correct for MD5 but may not be always the password that the user set. (it's a very small probability). A collision is two different input data and one same hash result. I use it as a reverse security tool : if my program finds the password then it automaticaly disable the account and ask the user to input a new password. A final note : once revealed, a password is useless.

Here is an idea: if you are using MD5 to store password hashes which are compare to verify user passwords, what you can do is to migrate each password next time the user logs in. You get the original password from the user for verification. If it fails, tell the user it is invalid, but if it succeeds you can migrate the password to SHA1/256 then. To know whether a password hash was already migrated or not, you could store in the password hash database field something like SHA1:<hexadecimal-sha1-hash-value-here>. So, next time you check, if the password hash field starts with SHA1:, it is migrated, otherwise it needs to be migrated.

I'm going to say set the default encryption type on your authentication solution to SHA and then set every user account so they have to change their password on their next login. First, pretty much every authentication solution supports that. Second, it's easy. Third, if you are asking the question you probably have some concerns that their current passwords have been compromised, so that would be the safer solution. The only thing you have to do in follow-up after that is put password change requests, because the user has been "locked out," under monitoring and require additional information to combat social engineering and to get some forensic information if the person making the request has actually tried to change their password. That at least gives you some idea if your passwords might have been compromised. You'll need a script for the help desk people, however, so you ensure they don't reveal to a social engineer that you are paying extra attention to people who can't login.