The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

well, first of all they should never gain access to your hash, but we all know it could happen.
but there is another step you can do.

the term is called 'salt'

basically, you concatenate a string to the password which was submitted.

PHP Code:

$salt = 'whatever';

$hash = md5($salt . $_POST['password']);

// now check your db to see if the hash matches whats in the db

this makes sure that the string they submit will not be directly md5()'d and checked against the db value. it will be modified, so this prevents them from finding a string which will produce the same hash. once you add the salt, the string they submitted will now produce a completely different hash.

you must use the same salt when you origionally store the hash in the database, and when you check if the submitted password matches the hash in the database.

im not an expert on this type of stuff, and i encourage you to take what i say with a grain of salt(no pun intended lol)

Have a look on the php function overview of md5 for some ideas on creating a 'better' hash. There are other encryption methods such as the crypt function with the ability to use md5, sha1, blowfish etc. as the encryption type.

I think I read somewhere that someone had found a way of getting collisions (i.e. finding two different strings that both give the same hash) using SHA1, but that it takes a lot of CPU power to do that.

I'd suggest using SHA1 anyway or even better, a combination of the two, e.g. split the password in two, and then hash one section with MD5 and the other with SHA1, concatenate them and then store that as your password hash

Heh, I've created a couple of apps for my old employer (a bank) and used lots of tricks like that. Security guys dig them (even if I'm not 100% sure that the MD5.SHA1 trick is actually safer than just a SHA1 on it's own).

I would not make your application more secure. You can md5, sha etc a password as many times as you want but it will not make it more secure. If your trying to brute force it you will try all of these different methods each time anyway just incase.

And for everyone screaming that md5 is not secure anymore, it is as secure as it ever was. As long as you put a real salt to the password it will take months to find a collision, i.e. the longer the string, the more different letters/symbols the longer it takes.

You can bruteforce a 4 letter password in under 30sec, if the password including the hash is 200 characters long and a mix of different letters, numbers and symbols it will take months.

And lets not mention, that if someone manages to get ahold of your hashes it does usally mean they already got a entry to the system...

Technically, MD5 cannot be decrypted, as it's not encryted data, but a hash of the data.

You can, however, generate collisions - finding different strings which give the same MD5 hash.

Bottom line though, is that it's not as safe as people once imagined. A friend of mine had two machines set up at home generating hashes and storing them in a database. He let them run for a month (I don't even want to know how much disk space he used for that) and then, for a laugh, we searched for the hash of my favourite password. Oops, we found a match...

There was an engine on Google I found a while back that did the same thing.. It had a DB of thousands upoon thousands of hashes... It stored the unhashed and the hashed... You entered the plain text and it would give you the hash ( easy ) but then you enter the hash and it gave you the plain text. It was pretty scary.

But as it was said before.. This is nothing more then a Brute force... as far as it taking months I am not too sure about that... SOmeone can let a very decent computer run for about 3 days and get a password dictionary that is very impressive.

Bottom line.. USE SALT.. USE PASSWORD KEYS and everything you can to fool your intruder... I think it's a game...

*** And correcting my first post ****
MD5 can't be decrypted in the normal sense.. Unless you are a math genius and somehow figure out how the symbols relate to the letters and so forth. That would be the only way... But the thing is.. is that the user can't enter the HASH into the form to login.. It has to be the the plain text.. And if the intruder has your hash then he has already hacked your database and doesn't NEED to login through your PHP.. lol he can download it and take out the session requirements...

And for everyone screaming that md5 is not secure anymore, it is as secure as it ever was.

yes and no. If you look at just the MD5 schema, then yes the security has not changed, but that is not the whole of security. Part of security is also how expensive it is for an attacker to break through. For example limiting the number of allowed login attempts is more secure against brute force than not limiting, because successfully carrying out a brute force attack is much more expensive and difficult to do.

MD5 collisions have always been possible, but were long considered so improbable that the effort required to find one was far too expensive for computers to efficiently carry out in a reasonable time. But technology changes, and better technology means that the "less secure" hashing algorithms that not too long ago were considered pretty strong (like MD5 and SHA1), become less secure in the face of new technology. Today, you can probably find an MD5 collision with a single home PC in under 3 days. There have been a number of case studies and proofs to demonstrate that MD5 collisions are not longer in the realms of "improbable" and "expensive" as many once thought. There have also been some cases showing that SHA1 collisions are easy to find with today's technology.

For password hashing, I would say no hashing algorithm less than SHA-256 in addition to other standard precautions like salting would be the minimum security you'd want for a new application you're building.

Originally Posted by Mav3n

And if the intruder has your hash then he has already hacked your database

Not necessarily. You would probably be surprised at the number of applications whose "auto login" feature stores your password hash in a cookie. It could also be intercepted if the SQL server is on a different machine and a hacker is listening between the two. It could also be intercepted by examining the SQL logs. There are a number of ways to get a certain price of info in a database without hacking into the database itself.