The documentation says: "An optional salt string to base the hashing on. If not
provided, the behaviour is defined by the algorithm implementation and can lead to
unexpected results."
Ok I only read the German manual. Here the documentation differs and no hint is given for
"unexpected results".
But even with this hidden hint in the English documentation I cannot agree to
your argumentation. I set the salt as an empty string,
so I provided the second Argument, even if it was empty. And what I got was no
hashed string. It was an empty string.
So I expected as result always an hash string, weather or not there is an empty
salt-string. And under Debian lenny there was always a non-empty hash-string,
even if the salt-string or both arguments were empty.
Example in Lenny:
$ php -r 'var_dump(crypt("",""));'
string(34) "$1$S5KCztpy$mu6mdwHz0weoCkGKGqX2s0"
Example in Squeeze:
$ php -r 'var_dump(crypt("",""));'
string(0) ""
Maybe you say, this is no critical behaviour. But I just migrated some servers
from Lenny to Squeeze and one website
on these servers got involved by this phenomenon (login script, that did no
check for empty strings, because it thought, it
gets always hash strings as results -> worst case occured -> login without
valid password).
So in my opinion it could be advisably to bring the patch also for the current
stable Squeeze release, because other
web2.0 websites with login could probably be affected / vulnerable in the same
way leading to a significant
risk concerning privacy for the users of those websites.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
