Re: password hashing and crypt()

Nathan Nobbe wrote:

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

crypt has some issues which I haven't seen anyone else mention. The salt is actually contained in the crypted string as the first two characters, there's no need to store it separately. <?php $string = '12345678'; echo crypt($string, 'ab') . "\n"; ab1iBa.N.U2C6 echo crypt($string, 'cd') . "\n"; cdsmm9tFWz3CI The next problem (more importantly) is that crypt only looks at the first 8 characters when generating a hash. It doesn't matter how big you make the string, it's the same as chopping it off at 8 characters. echo crypt(str_repeat($string, 40), 'cd') . "\n"; cdsmm9tFWz3CI The man page explains this (I think): http://linux.die.net/man/3/crypt However if you use md5 or sha1 or something else, then yes store the salt separately because that is *not* part of the hash that gets returned. -- Postgresql & php tutorials http://www.designmagick.com/