Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain openwall.com designates 195.42.179.200 as permitted sender)
Date: Mon, 18 Jul 2011 02:51:27 +0400
To: Joey Smith <joey@joeysmith.com>
Cc: PHP Internals List <internals@lists.php.net>
Message-ID: <20110717225127.GA19832@openwall.com>
References: <20110717182616.GA17288@openwall.com> <20110717222915.GA14497@joeysmith.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110717222915.GA14497@joeysmith.com>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [PHP-DEV] [PATCH] crypt_blowfish 1.2
From: solar@openwall.com (Solar Designer)

On Sun, Jul 17, 2011 at 04:29:15PM -0600, Joey Smith wrote:
> On Sun, Jul 17, 2011 at 10:26:16PM +0400, Solar Designer wrote:
> > + * For actual implementation, we set an array index in the variable "bug"
> > + * (0 means no bug, 1 means sign extension bug emulation) and a flag in the
> > + * variable "safety" (bit 16 is set when the safety measure is requested).
> > + * Valid combinations of settings are:
> > + *
> > + * Prefix "$2a$": bug = 0, safety = 0x10000
> > + * Prefix "$2x$": bug = 1, safety = 0
> > + * Prefix "$2y$": bug = 0, safety = 0
> 
> If I'm understanding the change correctly, we should now be advising
> users to transition their code to '$2y$' rather than '$2a$', with

Yes, but this is not terribly important.  In practice, "$2a$" is almost
the same as "$2y$".  For passwords that don't contain the '\xff'
character (which is not even valid in UTF-8 sequences), these two are
100% equivalent.  For 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.

> 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.  This 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.

Thanks,

Alexander