Hi.
I'm about to start making the usual form-based log-in deal in PHP, but would like to develop one that is really secure, so it's actually worth reusing... I've just been told that md5 hashes can now be "handled" in about an hour, by an average machine bombarding with randomly generated md5 hashed strings. What's the alternative? Running an md5 on an already md5'ed string?
well you could take whatever you want to encrypt (passwords i presume) and then prepend and append it with random data before you md5 hash it - e.g. they provide password of "liverpool" (say, for no particular reason), then rather than md5-ing "liverpool" you could md5 "$42hsbK7%3liverpool23G14$*aoe". That way you're making anything you're trying to MD5 much more random that it would be and protecting from a pre-generated MD5 dictionary attack, and you're going to greatly increase the length and complexity of any password that anyone enters.
As long as you prepend and append with the same random string when you're checking against the MD5 then it should make it more secure. unless of course someone hacks into your webserver and sees what you're prepending and appending to the data in your PHP script, but then i guess you've got bigger problems if someone does that...
(edit)
sorry have just realised that you might be wanting to protect against attacks with someone entering random strings into the log in form? in which case it doesn't matter what you use to encrypt the data, if you allow someone to try as many passwords as they like and just keep returning them then they'll eventually hit on the right one. If that's what you're worried about then you should maybe log the IP of the attempted entry - then if you get 3 wrong attempts in, say, a minute, then have the script reject login attempts from that ip for an hour. Not fool proof, but a good start. of course, if you get repeated password fails on a particular username then you should deactivate the account and send an email to the account owner.
Does either of the above help?
(/edit)
The problem with MD5 is collisions - e.g. a string of "mypassword" might collide, or have the same hash, as a string like 'S%@msdH#JK@*GHSM#%%%'. As for "running an md5 on an already md5'ed string," you're only increasing the likelihood of collisions IIRC. So even salting an MD5 string as suggested above won't help you much, because the "cracker" probably never even gets your actual password - it just finds a string that comes up with the same hash.
If you want a simple alternative, use PHP's [man]sha1[/man]. Cracking a SHA1 password would take significantly longer than an MD5 password.
If that's not enough, you could go all out and use a salted encryption method with one of the algorithms in the [man]mcrypt[/man] library, though this would mean that your script could only be distributed to servers that have the mcrypt lib installed.
Your premise is basically flawed:
You seem to think that md5 is an encryption algorithm, or cipher, which it is not. It is a hashing algorithm which is something entirely different.
You may be designing your application's security based on the premise that someone will obtain access to your database. This is pointless- if someone obtains your database, all bets are called off immediately!
By all means hash the passwords in the database, but it is FAR MORE important to ensure that the database is not compromised than to think of a really clever hash function.
It's useful to note that at some point in the future, your application may be replaced by another one- if the data are to be migrated and that application is unable to reproduce your complex hash function, all users will need new passwords.
Mark
markR: so what you're saying is that proper input validation is really the toppriority?
spookztar wrote:proper input validation is really the toppriority?
No, I'm not.
I'm saying that you should consider the security of your application as a whole, with a view to preventing any unauthorised access via vulnerabilities in your code, other software, the host OS, or any other route.
You'll realise that in some cases this means you may have to change hosting provider, if your current one won't give you a server shared with nobody else.
Mark