Hi Aaron, Storing the hash in the database is just another level of complexity. As long as your hash isn't a dictionary word, you are as safe as the first method when hardcoding the value.
The only way it would fall down is if someone had access to the code, but then the hash value is going to be the least of your worries... -Stig Philip Arndt wrote: > Hi Aaron, > > I've used option 1 before, and I believe it is the most secure method. > > Just randomly generate a string. > > Basically you are making it as hard as possible for someone just > looking at the database to be able to brute force the passwords out as > they have to add the salt to each password which makes it takes years > and years. > > If you hardcode a global salt it can make it slightly easier but is > still more secure than not using one! > > Cheers, > > Phil > > On 6/11/2008, at 11:25 AM, Aaron Cooper wrote: > >> Hi All, >> >> I'm looking at methods of hash salting in relationship to >> registration and login user functionality. >> >> I've looked at three methods for storing the salt. >> >> 1. Add another field to the user table for storing the salt (in plain >> text) that was generated randomly upon registration. (or use another >> peice of user info, like registration date) >> >> 2. Hardcode a global salt value >> >> 3. Both >> >> Anyone care to discuss which, if any, is the prefered method? Is the >> extra query work for the database method a big issue for large user >> bases? >> >> Cheers >> Aaron Cooper >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
