0

I'm trying to import users credentials from one database schema to another one without users needing to create a new password, So first user table (the one I need to import to the new site) uses sha256+salt(I think) and my new site is using md5+salt (I think) I have access to all files and stuff so I could locate the salt that's being used if I can somehow reverse engineer the sha256 to make it md5?

Is there a way to do this? if so how would I approach it? an example of the password would be:

old site: e3e922af8a36de975983b075b3bf5336bbb26c8008aa5d9b39aef8d85cb7eb32

new site: $S$Dbj.yBTjHV97QNLHwuoykWxzpNL9bxxFl4b8uoP1u1rJzCyDZb.e

I'll appreciate any input, Thank you!

Update: new site uses base64encode + salt which I know what is, just to be clear I'm not trying to actually be able to see their password in plain text, Can I convert sha256 -> base64encode with some mysql commands or something if I know the salt?

paultheprogrammer
  • 7
  • 1
  • 1
  • 4
  • 4
    If you can reverse engineer a sha256 hashed value you will be set to make some big bucks. A hash, by very definition, is one way; you can't unhash a value. The real question is why do you feel a need to change hashing algorithms? – Sam M May 16 '19 at 16:42
  • You would always need to repeat the sha256() process on the new site, you could possibly then md5() that and integrate it with the new mechanism, you would need a full understanding of both processes to do that. (The new site example is not hexadecimal or base64 to there is some other encoding going on) – Alex K. May 16 '19 at 16:42
  • 2
    Why on earch do you want to switch from sha to md5? I'd understand if it would be the other way around. In that case you would need to migrate every user one by one when they login to your site. At that point you have their plain passwort and can rehash it. – Paul Spiegel May 16 '19 at 16:45
  • 1
    Your new site isn't using md5 anyway. It looks like the result of PHP's [password_hash()](https://www.php.net/manual/en/function.password-hash.php) using its default algorithm, which is bcrypt. – Bill Karwin May 16 '19 at 16:47
  • The old site's hash is a 64-character string of hex digits, so it could be the result of SHA256, but there's no way to know if the input included a salt. – Bill Karwin May 16 '19 at 16:50
  • Update: new site uses base64encode + salt which I know what is, just to be clear I'm not trying to actually be able to see their password in plain text, Can I convert sha256 -> base64encode with some mysql commands or something if I know the salt? – paultheprogrammer May 16 '19 at 17:30
  • **DO NOT USE MD5 FOR ANYTHING RELATED TO SECURITY, ESPECIALLY PASSWORDS**. As an absolute baseline use a **password specific hash like [Bcrypt](https://en.wikipedia.org/wiki/Bcrypt)**. Even SHA2 is a massive liability as Bitcoin mining has made SHA2-256 hashing extremely efficient and cracking even eight letter random passwords is now practical with enough GPU hardware. – tadman May 16 '19 at 17:57

1 Answers1

0

Unless you're prepared to crack their password, no, you can't convert as SHA2-256 hash to an MD5 one. You need to know the content that generated the hash in the first place.

When migrating from one hashing type to another the best plan is to normalize all your password hashes into a consistent form first and the Modular Crypt Format is the most widely supported.

If you can wrangle your old hashes into that form then you should be able to use them with password_verify. You can also update user passwords as they log-in by re-writing them with password_hash which uses Bcrypt by default.

Over time you can stomp out old SHA2-256 and MD5 passwords and limit your exposure.

tadman
  • 208,517
  • 23
  • 234
  • 262