Nathan Nobbe schreef:
hi all, recently ive been debating a bit about the use of the crypt() function and the best practice thereof, im hoping you can help to clarify this for me. so, the crypt function http://www.php.net/manual/en/function.crypt.php has a second parameter, $salt, which, if not supplied will be automatically generated and presumably become a prefix or suffix of the returned string. now, the article on the phpsec website http://phpsec.org/articles/2005/password-hashing.html recommends to externally create a salt and to store that in a separate field in the database, which would then be used for subsequent password verification. theoretically, however, if the password is generated without a user supplied salt, there is a salt already embedded in the password anyway. so, i have the following questions 1. is the phpsec technique bloated or unnecessary
I can't see a dictionary attack being thwarted by the salt given that the salt is made available when a password is checked. I'm struggling to see how a salt will help if it's made available. but it's late, may be better brain can enlighten us :-) then again your question is a little skewed due to the fact that sha1() is used in the phpsec article and your talking about crypt - which encryption is better as it stands is the first question to ask no? AFAIK sha1() is recommended over DES but maybe I'm misinformed.
2. is it better to create a user supplied salt, and why or why not 3. is crypt() 'intended' to be used w/o a user provided salt, since it is a stable algorithm
depends on the use - i.e. using it inconjunction with a .htpasswd file will required no salt (auto-generated salt), other usage recommends using an explicit salt. all this salt is hurting my eyes - I have a blind spot.
any other direction or hints you can supply are much appreciated. thanks, -nathan
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php