Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54004
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20110717225127.GA19832@openwall.com>
References: <20110717182616.GA17288@openwall.com>
	<20110717222915.GA14497@joeysmith.com>
	<20110717225127.GA19832@openwall.com>
Date: Mon, 18 Jul 2011 01:23:40 +0200
Message-ID: <CAEZPtU7kvsphO73_pf-830g8ra_A5G3PG-C0Qk1CjSYMYWVYLw@mail.gmail.com>
To: Solar Designer <solar@openwall.com>, Ilia Alshanetsky <ilia@ilia.ws>
Cc: Joey Smith <joey@joeysmith.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PATCH] crypt_blowfish 1.2
From: pierre.php@gmail.com (Pierre Joye)

hi!


Thanks for the patches! Very welcome :)

On Mon, Jul 18, 2011 at 12:51 AM, Solar Designer <solar@openwall.com> wrote=
:

> Yes, but this is not terribly important. =A0In practice, "$2a$" is almost
> the same as "$2y$". =A0For passwords that don't contain the '\xff'
> character (which is not even valid in UTF-8 sequences), these two are
> 100% equivalent. =A0For realistic passwords that do contain this
> character, I had one "hit" in 150,000+ such passwords tested:
>
> http://www.openwall.com/lists/oss-security/2011/07/08/1
>
> So this is negligible, and even for the affected passwords (where "$2y$"
> and "$2a$" hashes differ by more than just the prefix) this only matters
> if those password hashes are ever migrated to other systems (non-PHP).
>
> The reason why I went for this is that I consider the security advantage
> of avoiding easy collisions with the buggy hashes non-negligible.

Makes full sense.

>> perhaps a note mentioning the '$2x$' prefix for "transitioning users
>> with passwords that contain non-ASCII characters with the 8th bit set".
>
> We need to be careful here such that no one starts using this for newly
> set passwords. =A0This bit of documentation should be available to those
> few who actually need it (I expect that most sites won't care), but
> maybe it should not be on the function crypt() documentation page.
>
>> Obviously, any documentation change in this regard will need to be
>> pending on the version these patches get rolled into...
>
> Yes - need to release PHP versions with this code first.

I think we should push this patch to 5.3 now as well, so it will be in
5.3.7, it is important enough.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org