-1

Before knowing about just how dangerous md5 is, I have used it to store passwords. Md5 is terrible for security, and can easily be decoded. I now have 70,000 users registered in my database. Big mistake.

Now, since MD5 can be decoded into a string easily I was wondering if it is possible to loop through everyone's password in my MySQL database, decode it, and change it to a much stronger salt hashing system where it cannot be decoded to a string again. Would this be a viable option or even possible? Or is my only solution to do a hard database reset. Prompting users to change passwords would not be a good solution.

JavaC3code
  • 159
  • 1
  • 8
  • 5
    It is _not_ possible to "decode" an md5 hash, that is nonsense. It is a hash, that means it cannot be decoded. Reason is that a hash does _not_ hold all information of the original phrase, hashing reduces the information. You can get around it, though, guess the original password too easily. – arkascha May 02 '17 at 14:10
  • *Hm...*, not sure about this. If you can't find a way to fix/do this, then you could instruct your user base to reset their passwords, that's all I can think of. – Funk Forty Niner May 02 '17 at 14:10
  • how did you accidentally use `md5` and then put it in production. very interesting – Rotimi May 02 '17 at 14:11
  • 5
    *"Prompting users to change passwords would not be a good solution."* - Why not? Without knowing what their passwords were, there isn't much you can do about it, sorry. And you can't unhash a hash. (as already stated). – Funk Forty Niner May 02 '17 at 14:11
  • 1
    you just answered your question. tell your users to change their passwords – Rotimi May 02 '17 at 14:11
  • Food for thought; having kept the md5'd password (column) and adding a new column to it and then when they updated their passwords (password_hash'ed) using a boolean flag would have made this process a lot easier and pain free. Or, created a new relative table. – Funk Forty Niner May 02 '17 at 14:13
  • `Accidentally` ? – Masivuye Cokile May 02 '17 at 14:14
  • @Fred-ii- not even required, since an authentication algorithm can easily determine what hashing algorithm has been used for a given hash. That means you need neither a flag nor a second column. – arkascha May 02 '17 at 14:14
  • @arkascha *"That means you need neither a flag nor a second column."* - It's an option, not a requirement. – Funk Forty Niner May 02 '17 at 14:15
  • @Fred-ii- Ok, agreed. But it is an unnecessary complex option. :-) – arkascha May 02 '17 at 14:16
  • @arkascha I've seen similar questions like this before a few good solutions that also talk about using a boolean flag. I should have elaborated on that "boolean flag" stating that if they changed their password to be the safer hash, then nothing else needs to be done. However, if the OP's user base is (pardon the expression) "damned", then they might not have a choice *but* to inform their users to set a new password. – Funk Forty Niner May 02 '17 at 14:18
  • Here is a relevant post [Converting md5 password hashes to PHP 5.5 password_hash()](http://stackoverflow.com/q/18906660/1415724) which could be a duplicate to this question. Edit: To answer your question here @arkascha or possibly ;-) – Funk Forty Niner May 02 '17 at 14:21
  • @Fred-ii- I can't follow, sorry. As pointed out in the answer below this can be done hidden in background, since every returning user has to provide a password. So the hashes can transparently be replaced. No flag or column required. Though certainly it is possible to use them, sure. – arkascha May 02 '17 at 14:21
  • *No flag or column requried* the answer below does state that a new column is needed @arkascha – Masivuye Cokile May 02 '17 at 14:23
  • @MasivuyeCokile Those are separate issues. I referred to the answer for pointing out that the passwords are known and can be rehashed in background. I do _not_ agree that an additional flag or column is required. _What for_? – arkascha May 02 '17 at 14:24
  • ...this question is starting to look more like an opinion-based *lol* – Funk Forty Niner May 02 '17 at 14:25
  • True -- you only need a new column if your existing one is not wide enough to hold the `password_hash()` output. – Alex Howansky May 02 '17 at 14:25
  • @arkascha Yeah; John Lennon said something to that effect once ;-) just in a slightly different context. – Funk Forty Niner May 02 '17 at 14:26
  • @AlexHowansky That is true, indeed. – arkascha May 02 '17 at 14:26
  • @arkascha *lol* I see all ``. – Funk Forty Niner May 02 '17 at 14:28
  • man; had I knew the OP accepted that answer, I'd of put in my comments to an answer instead. – Funk Forty Niner May 02 '17 at 14:28
  • lol too late @Fred-ii- – Masivuye Cokile May 02 '17 at 14:29
  • Ha ha @Fred-ii- that's why I was typing my answer as fast as I could and not reading the comments. :) – Alex Howansky May 02 '17 at 14:29
  • [*Missed it by "that" much...*](https://www.youtube.com/watch?v=oPwrodxghrw) @MasivuyeCokile – Funk Forty Niner May 02 '17 at 14:30
  • ........nah. Just to set the record straight @arkascha two different animals here ;-) coffee junkie, yes. – Funk Forty Niner May 02 '17 at 14:31

1 Answers1

7

No. However, you can work around it, sort of:

  • Add a new field to your database to hold a second password.
  • Allow your users to log in as normal, with the MD5 system.
  • After they have successfully authenticated, you know their password. So now just use password_hash() on it and store it in the new field.
  • After some amount of time has passed, all active users will have their password encoded both ways.
  • Remove the MD5 authentication and replace it with password_verify().
  • Any users that hadn't logged in during the transition period will simply have to reset their password.

Keep the transition period as short as reasonably possible. This will allow your most active users to transition transparently without having to leave your system exposed for too long.

Note -- ultimately, you should have them change their passwords, as the current ones should be considered weak.

Edit for clarification:

You don't necessarily need to make a new password column. Since the hashes generated by password_hash() can be easily differentiated from those generated by md5(), you can simply use a strlen() check to determine which method to use. However, if you made your password field exactly the width of an MD5 hash string, then it's not going to be wide enough to hold the output of password_hash().

Alex Howansky
  • 50,515
  • 8
  • 78
  • 98