When I encrypt a password in a Mysql database using SHA1 or MD5, my PHP scripts appear unable to decrypt them.
e.g.
Say the password is 'password'
The code:
$p = 'password';
SHA1($p);
or md5(''password')
;
does not work. Even when I type SHA1(‘password’) into the SQL command prompt i simply get empty set.
Does anyone have a clue?
I thought it might be something to do with my MYSQL installation. I am using MySQL 5 and PHP 6
Thank you
Thats because you cannot decrypt MD5 or SHA password hashes.
The hash is basically like its unique fingerprint. You can’t build a person from it can you but its unique. Thats how you think of MD5 / SHA hashes.
You hash a string its a one way process. What you then do is to compare the hashes against each other instead. This stops the admin of being accused of knowing the password etc.
thanks for replying…
if i might ask one more question.
how do i do a password check using either of these
if ( $password_from_db == sha1( $password_from_user ) )
logic_earth has given you a code sample.
Someone pass the salt.
What, are you from the future?
PHP 6 has been put off pending resolution of the Unicode problem which has proven to be far more difficult than anyone anticipated. Next PHP version will be 5.4.
Vinegar too? 
Seriously I don’t worry about SHA and salt I just md5() things. I doubt there are many people who can break MD5. I know its theoretically possible but I would imagine there are VERY few people who can do it.
Your liability, not mine.
Everything can be cracked Michael, SSL is supposedly secure but there are ways to crack that too. At the end of the day you take risks with everything you do. You could be run over by a bus next time you cross the road - do you stay inside every day to avoid that?
If an attacker wants to exploit a MD5 hash first they need to know the site uses it (hence I’ve not declared any of my sites) and then secondly they’d need to be able to alter my php because I hard code secondary checks into everything - I don’t just rely on mysql to check data.
If someone is determined enough to attack a site and they’re good at doing it then nothing will stop them anyway because they’ll still find a way of doing it regardless.
Everything can be cracked Michael, SSL is supposedly secure but there are ways to crack that too. At the end of the day you take risks with everything you do. You could be run over by a bus next time you cross the road - do you stay inside every day to avoid that?
No. I look both ways before crossing. By your deeply flawed logic I just cross without looking.
The purpose of salt is to stop the attacker from using the exposed passwords of your users to attack other sites. Users have a nasty habit of not varying passwords. Without salt a rainbow table can be used to work out the most likely password based on the hash and then use that to try to log into banking sites and other more valuable accounts.
If they succeed and the breach traces back to you, you’re liable. Salting passwords is a standard industry practice, and in failing to follow that practice you are negligent, and can be proven such in a court of law.
So again, your liability - your choice.
Besides, I seriously doubt your “hardening” or your “secondary checks” are worth anything if you cut corners as basic as salting. There’s something to be said for craftsmanship and quality control.
Again as I’ve said if someone attacks the site in the first place they’ve got to know its weaknesses. If they then crack the hashes and work out a bunch of passwords then THEY are liable - not me.
You’re paranoid about the law. I’ve no idea whats happened to you in the past but not everyone is paranoid and I’ve yet to hear of a web developer ever being prosecuted because someone cracked the database on a site that was hacked by someone else. Additionally perhaps then php should withdraw md5() if its so dangerous because otherwise they’re also liable for many web developers the world over having insecure websites. Heck, I better go and sue them now for not doing so because I’ve just been insulted by you because of their negligence. Further if the user is stupid enough to use their banking password on other sites then they’re at fault for disclosing their login credentials to a third party - and that is explicitly forbidden by pretty much every bank on the planet. I don’t suppose you thought about that did you.
Also if you want to deform my work on a public forum without seeing it then perhaps you should be paranoid about liability because I may very well seek legal advice the next time you do so.
Now, if you’d care to stop being so arrogant perhaps we can just go back to normal.
Why is it you think that knowing how to download a file is something that few people would know how to do? All anyone need do is find and download the table and they can then just look up the MD5 hash to find a value that will generate that hash - it may not be the actual password that the account is using but it will work just the same.
MD5 was designed for being able to verify that files haven’t been tampered with by comparing the MD5 hash of the file at different times, it was never really intended for hashing passwords as it isn’t really all that secure for that purpose.
Using a salt with MD5 at least means that the easily downloadable lookup table cannot be used.
Plenty of sites offering such downloads - take a look at http://www.google.com/search?hl=en&q=md5+rainbow+table+download&aq=f&aqi=g1&aql=&oq=
At least you’re polite about it 
The fact remains though that many people do still use md5 irrespective of whether its a good or bad idea. I’ve never said I don’t think people don’t know how to download a file. While we’re on that however, most (and I’m not excluding hackers etc) people don’t know how to download a mysql table from joe blogg’s website. 1) it’s not normally in public_html and 2) they’d need to be able to hack in to get it anyway. While 2 is possible it doesn’t mean that everyone can do it or that those who can will even target that site.
The op wasn’t asking about the security of it they were simply asking how to decrypt hashes whilst showing code which generated them. A simple explanation was provided and then the next thing I know the security paranoid are jumping in trying to cause a spat and frankly there wasn’t any need for the tone.
It’s also very well banging on about using SHA and salt but neither of you have actually provided any sample code as to how to use it.
Unless you’re willing to do so then its a bit pointless really. We can all preach about various aspects of computer security in general ‘vague’ speak but unless you’re going to get your hands dirty then there’s no point specifying vague talk and then insulting other people in the process of being completely unhelpful.
Actually decrypting md5 that has not been salted is not that difficult. You would be surprised. Since many people use regular english words for password makes it even easier.
Salt is not a bad practice and not hard to implement at all. also SHA256 is much better than md5 and is available in php, not sure about mysql.
Again, vague talk with no actual code being shown. While I know its not hard to come up with a bit of code (unlike many I search for answers) I’ve said it above.
We can all post vague ‘clever’ sounding security talk but its actually getting your hands dirty and posting samples that makes you the expert you claim to be.
Thats like me telling someone who’s never used a computer that they need a firewall to keep their computer safe. Unless I recommend one and tell them how to set it up them its pointless but makes me sound like an expert.
See what I’m saying?
Additionally you’re all forgetting something: If salt is a hardcoded string or a random one stored in a DB then if the hacker has gained access to the site then how on earth will they not be able to find and use the salt to decrypt things?
I think the real issue here is the preference of SHA methods over MD5. The salt thing which Michael has stirred up seems irrelevant.
Salting a hash just makes an other hash for the same password.
E.g.:
$salt = rand(9999, 999999);
// Store in DB...
$hash = sha1($password.$salt);
The next time you want to check the password you compare:
$salt = getFromDB();
$hash = getFromDB();
if($hash === sha1($password.$salt) { ... }
As you use different salt for each and every user you reduce the possibility of successful rainbow table attacks - and that is a huge improvement in security, so not irrelevant.
Storing the salt is by the way no problem - you can not rebuild a password from it’s hash, even if you have the salt - you would still have to make hashes for each possible password with the given salt.
If you don’t understand why, it’s simple: they have to generate tables for every password combined with every possible salt.
Expecting one million possible salts (there are far more) they would have to store one million hashes - for just ONE password…so think of 1000 passwords, that would be one billion hashes.
If someone gains access to the site then they don’t need to work out any passwords as they already have access to all the content of the site.
The only thing working out what the passwords are would give them is the ability to break into other accounts that the users may have elsewhere and ANY salt will prevent that as long as the other site isn’t using the same salt - since using the same password with different salts will produce different hashes.
thank you everyone for the inciteful debate…what i have discovered then is that i am screwed!