[php-maint] Bug#623220: Bug#623220: Bug#623220: php5: crypt() function with empty salt, returns empty string

[Ondřej Surý]

Hi Michael,

On Mon, Apr 18, 2011 at 20:32, Michael Neubert
<debian at michael-neubert.de> wrote:
>>  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".

You should probably fill a documentation bug at bugs.php.net.

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

Even though I think that it's the application which needs fixing and
the implementation follows system crypt (which will return empty
string in case you provide the empty salt), you have convinced me that
it's worth fixing in squeeze.

Raphael could you please cherry-pick 58f8b27 to debian-squeeze and
include it in next batch of security updates?

O.
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/