Ashje
04-20-2009, 10:45 PM
Stop Using MD5
I recently got a comment on the tutorial entry about securing our hashes that felt like it should be turned into it’s own warning, passed on to all readers. Unfortunately, the poster didn’t give me any information, so I can’t credit them - but here’s what they said about why you shouldn’t be using MD5:
You know, it’s really frustrating seeing people trying to pass off obscurity for security. It doesn’t work. It never has. Don’t do it. Don’t promote it. Because, when you do, it damages security overall.
MD5 has been known to be useless as a security measure for well over a decade. Why people keep using it I will never know. Especially, when the SHA family is *vastly* more secure and available in all languages. Here’s the PHP page for hash():
http://ca3.php.net/manual/en/function.hash.php
Just use SHA256/512 and be happy until the winner of the NIST contest is found. Then use that.
At any rate, your ’salt’ completely misses the point of MD5’s weakness (btw, that’s security through obscurity which is completely useless). As in, if they have access to your DB, then chances are that they have (or could have) access to your source as well. Also, I could generate a collision to that password in well under a minute:
http://eprint.iacr.org/2006/105
So, I might not have the actual password. But, I’ll certainly have *a* password that will generate the same hash. If it doesn’t work, then I look at the source and find the obscuring factor, make a minor adjustment to my collision finding code and rerun. In seconds I’ll start getting positive results. Yes, it *is* that easy.
If you want to migrate people over to the new hash, then just create a new column in the DB which will hold it and set it to null. Then on login, if this value is null redirect them to a change your password page. *Require it*. Then after some months, drop the MD5 column, clean up the logic and have the remain inactive users use the forgot your password feature if they want to play again.
That might sound like a lot of work, but it really isn’t. Especially, when considering it’s the programmers fault for screwing up the security in the first place.
There are some good points made here - so if you’re using MD5 in your game for your hashes, you may want to look into updating your code.
Something I came across...
I recently got a comment on the tutorial entry about securing our hashes that felt like it should be turned into it’s own warning, passed on to all readers. Unfortunately, the poster didn’t give me any information, so I can’t credit them - but here’s what they said about why you shouldn’t be using MD5:
You know, it’s really frustrating seeing people trying to pass off obscurity for security. It doesn’t work. It never has. Don’t do it. Don’t promote it. Because, when you do, it damages security overall.
MD5 has been known to be useless as a security measure for well over a decade. Why people keep using it I will never know. Especially, when the SHA family is *vastly* more secure and available in all languages. Here’s the PHP page for hash():
http://ca3.php.net/manual/en/function.hash.php
Just use SHA256/512 and be happy until the winner of the NIST contest is found. Then use that.
At any rate, your ’salt’ completely misses the point of MD5’s weakness (btw, that’s security through obscurity which is completely useless). As in, if they have access to your DB, then chances are that they have (or could have) access to your source as well. Also, I could generate a collision to that password in well under a minute:
http://eprint.iacr.org/2006/105
So, I might not have the actual password. But, I’ll certainly have *a* password that will generate the same hash. If it doesn’t work, then I look at the source and find the obscuring factor, make a minor adjustment to my collision finding code and rerun. In seconds I’ll start getting positive results. Yes, it *is* that easy.
If you want to migrate people over to the new hash, then just create a new column in the DB which will hold it and set it to null. Then on login, if this value is null redirect them to a change your password page. *Require it*. Then after some months, drop the MD5 column, clean up the logic and have the remain inactive users use the forgot your password feature if they want to play again.
That might sound like a lot of work, but it really isn’t. Especially, when considering it’s the programmers fault for screwing up the security in the first place.
There are some good points made here - so if you’re using MD5 in your game for your hashes, you may want to look into updating your code.
Something I came across...