There are many ways to hash a password, salt is the most talking about to use with sha1 or md5. I have this sample example, and would let the reader decide which method is the best and if any ideas to improve it are welcomed OR if you got new way to secure a password.
$pass = 'somestring'; // password
$salt = '}#f4ga~g%7hjg4&j(7mk?/!bj30ab-wi=6^7-$^R9F|GK5J#E6WT;IOJN'; // random string
$hash = md5($pass); // md5 hash #1
$hash_md5 = md5($salt.$pass); // md5 hash with salt #2
$hash_md5_double = md5(sha1($salt.$pass)); // md5 hash with salt & sha1 #3
$hash1 = sha1($pass); // sha1 hash #4
$hash1_sha1 = sha1($salt.$pass); // sha1 hash with salt #5
$hash1_sha1_double = sha1(md5($salt.$pass)); // sha1 hash with salt & md5 #6
// echo now
echo 'Original Password: '.$pass.'<br><br>';
echo 'Original Salt: '.$salt.'<br><br>';
echo 'MD5: '.$hash.'<br><br>';
echo 'MD5 with Salt: '.$hash_md5.'<br><br>';
echo 'MD5 with Salt & Sha1: '.$hash_md5_double.'<br><br>';
echo 'Sha1: '.$hash1.'<br><br>';
echo 'Sha1 with Salt: '.$hash1_sha1.'<br><br>';
echo 'Sha1 with Salt & MD5: '.$hash1_sha1_double.'<br><br>';
In above, which one would one choose from #1 to #6.
Ideas and improvement in above code are welcomed.
Thanks
No real comment on the pro’s or against of the above with the exception of surely salted(rainbow tables), after that I would of thought it is really a case of speed(if there is a difference in md5 vs sha1 vs another) any way…
To me this about being able to sniff a password or get it from the data storage, but surely the weakness is a weak password. What I played with recently was cracklib, as it was django it was the python version, but I see a php version.
last time I looked into this you’re best off using simply using a single hash + salt.
Double hashing from what I’ve read actually makes it easier to ‘decode’. One step you may want to take is to store the actual salt outside of the scope of what is served on the site and included it using PHP itself. That way in the (incredibly unlikely) event that PHP stops functions but the server itself still works the salt itself isn’t visible and the include path is out of reach.
(to give an example, if your website root is /srv/www/htdocs, which is the default for openSUSE/Apache2 store it in /srv/www/ or /mysecretstuff/)
And of course don’t do something silly like storing the hash itself in the database (hey I’ve seen this happen) since the #1 threat is usually someone exploiting SQL injection and running off with your database. (Could also be a reason to store data other than passwords hashed, think usernames and/or mail adresses)
Should offer more than enough protection unless you’re working for a major bank or are storing military secrets… and if you are you’d probably be consulting the worlds experts instead of a random forum and would have the server itself heavily guarded to prevent physical access.
salt.php:
<?php
$salt = '}#f4ga~g%7hjg4&j(7mk?/!bj30ab-wi=6^7-$^R9F|GK5J#E6WT;IOJN'; // random string
?>
actual code:
<?php
include('../../salt.php');
echo sha1($pass.$salt);
?>
You pointed out good point, if the server/PHP stops working so in this case the user will be not able to see the salt unless s/he knows the directory listings.
I did exactly what you had suggested that one shouldn’t do. I stored the hashed passwords in my database. The inevitable happened…
My site got hacked (probably through SQL injection). The hacker gained access to the admin features in the front-end of the website. I removed access to everyone who logs in and this has temporarily stopped the crisis.
I’m now changing the query stored in php to parameterized stored procedures. This should solve the SQL injection problem.
But you had mentioned that the hacker would run off with the entire database. Does that mean that he already has the hashed passwords of my users?