The main purpose of salting is to prevent people from using MD5 dictionaries to find passwords. The online hash dictionaries available are actually pretty damn effective on weak-medium passwords. With salting, if they want to crack the hash, they need a truckload of processor power to do it. Without salting, in many cases you can easily recover the original password. With salting, it almost certainly falls into the too hard basket, but Stig makes a fair point about keeping the salt in a different place to the hashed password. You can always use hard coded salt in the application on top of a user-specific salt if you are concerned, to get the best of both worlds.
Nobody intentially leaves backups lying around, but cockups happen every day. It's nice to put some protection in place in case you make a cockup (for example I put my admin pages into robots.txt on the offchance there is a cockup with the login script) Harvey. Philip Arndt wrote: > Sorry but I've got to ask, why would you make your database backups > publicly available in a tar file??? > > The thing is, even if the salt is kept right there, it's a one way > encryption. They aren't able to reverse it back into its original > plain text format.. so despite the "keys being by the back door" they > can't do anything with them.. you merely add this value to the > password that the user posted on login in a particular way (end of > password, start of password, chopped up through the password) and > compare the encrypted/hashed value to the one stored in the 'password' > field and see if it's the same. > > Nobody should ever be able to find out the actual 'password' value > unless they're sitting in between the client and the webserver.. > > The procedure is really just to make sure that nobody looking at the > database table has easy access to all the passwords as they are one > way encrypted/hashed (malicious ex-employee, (google accessed 'tar > backup'??), etc.) > > On 6/11/2008, at 11:55 AM, Stig Manning wrote: > > >> You guys are very bullish on option #1. >> >> An interesting idea to bring up is the idea of having different >> 'security realms' so if one aspect of the application is compromised >> the >> whole is not. Leaving the salt in the same place as the hash is akin >> to >> leaving the keys by the back door. >> Having the salt hardcoded in the application, means that if someone >> manages to access your database, or as is more common uses Google to >> find a database backup in a tar file, they cannot see the salt and so >> the hash values are then worthless. >> >> Let me know what you guys think. >> >> -Stig >> > > > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
