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/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
