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] -~----------~----~----~----~------~----~------~--~---
