Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYkdBjoSpDJekPq=hxbty7GexkjyJnPNpH4vM4+v-v64Q@mail.gmail.com>
References: <CAGa2bXYP4L-EVjqiTvrOjbiRvzQJ7zyTQyu78O1AEEkk7nwEhQ@mail.gmail.com>
	<CAESVnVqBxo0VCYM_4V4_KzrD1+-F-0ipumrr_a=mAwaYje10Og@mail.gmail.com>
	<CAGa2bXa48gEEcE_DWE27B3UHD0Yi12bFVZsx-9t_anHunkj5Dg@mail.gmail.com>
	<CAHMUw2FLW06ABT=1RoH2gMuM7HbGDdSnLzxqfv8wNVp0rzfw+Q@mail.gmail.com>
	<CAGa2bXZF5sznggoYRFTtngO32b60NVG=6KqUBDB3guGb7_8oMA@mail.gmail.com>
	<CAHMUw2GyQOevKfZXuyd7S-PPUnShVVeoRvZNHK3q9w1yEe1wow@mail.gmail.com>
	<CADajX4C9sip=57QGaacZVq9cmAFhH6CJWpvSSjB7c921TGsJMQ@mail.gmail.com>
	<CAAyV7nFva4u-pW0Ago-VpkJ=-RuBvE_fjCg27Wza8_T6M0oYHA@mail.gmail.com>
	<CAGa2bXYkdBjoSpDJekPq=hxbty7GexkjyJnPNpH4vM4+v-v64Q@mail.gmail.com>
Date: Thu, 17 Jul 2014 17:56:52 -0400
Message-ID: <CAAyV7nF6HcdUcx_nYC2=87mkEGNk2AAhz3vtH9VGY0orwnzY+w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Adam Harvey <aharvey@php.net>, Tjerk Meesters <tjerk.meesters@gmail.com>, 
	Sara Golemon <pollita@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] crypt() BC issue
From: ircmaxell@gmail.com (Anthony Ferrara)

Yasuo

> Anthony, do you have suggestion for removing 72 char restriction of
> PASSWORD_BCRYPT?

My suggestion is to leave it there (it's no longer bcrypt if you do
something to remove it). Here's a deeper explanation:
http://stackoverflow.com/a/16597402/338665

Once scrypt (or yescrypt, or whatever comes out of PHC) gets crypt(3)
bindings, then we can implement that and pull it into the password
API.

Until then, implementing anything else is a step backwards
(crypt-sha256/512 is weaker than bcrypt, as is PBKDF2+sha512). So
since the 72 character restrict has little if any practical effect
(see my answer above), it's not worth making a practical weakening
(measurably harming everyone) of the overall algorithm for no reason.

My assertion is that, for the average developer, they are far more
likely to screw something up than actually improve security. The
documentation should be updated (and was, but instead of fixing a
misleading line, someone simply removed it, making the overall
statement more misleading).

Could we pre-hash internally ourselves? Sure. But at that point it's
no longer bcrypt (but our own hybrid) which was not what we were
after.

My stance here is that password_hash() should use standard algorithms
and formats **only**. The last thing we should be doing is inventing
crypto ourselves. Even if it "seems safe". Even if it "seems better".

Let's stick with the current implementation, make the "72 character
warning" a lot less scary, and move on. Once there are crypt(3)
bindings to a more secure algorithm (again, scrypt or yescrypt, or
whatever), then move to it....

Anthony