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.

Wish there was more?

I'm considering writing an ebook - click here.

.

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Tags: , , , ,

Tuesday, April 14th, 2009 code
  • SpyrosPan

    I can't really see why you think MD5 is weak while in fact this is far away from the truth. You imply that bruteforcing it is easy but this is definately not the case once more of course. But anyway, this is just an opinion.

  • Data33

    "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."

    Instead of having each player change their passwords, wouldn't it be easier to catch the posted password at login and perform the change automatically from md5 to whatever new algorithm you choose? Of course you'd also have to remove the md5 hash after changing it, or it would be sort of pointless.

  • Bob Dole

    Bah... the guy bashing security through obscurity is a moron or simply approaching the subject way too narrowly. First, no one is suggesting that you EVER use ONLY security by obscurity, but that you use it in addition to all other best practices as well. Not only that, but obscurity isn't limited by simply changing your database names from the generic 'password' name to something like 'pWord'. There are lots of things you can do:

    - Use Post instead of Get
    - Don't use common file names like admin.php, config.php, etc.
    - Hide your files by starting your directories with a period
    - Generate random field names for each users request.

    These methods aren't the end-all-be-all of security, but when used in conjunction with other best practices, they make it that much more difficult for a would-be villain to nab your stuff.

  • I use static salt, dinamic salt and sha1. A very good article about this can be found on CodeIgniter's Portal : http://codeigniter.com/news...

blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames