Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAAyV7nF6HcdUcx_nYC2=87mkEGNk2AAhz3vtH9VGY0orwnzY+w@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> <CAAyV7nF6HcdUcx_nYC2=87mkEGNk2AAhz3vtH9VGY0orwnzY+w@mail.gmail.com>
Date: Sat, 19 Jul 2014 10:59:24 +0900
Message-ID: <CAGa2bXaJBKL8b=ewy1VY5kWZ5G__yr=4kpJrFfxBrxr3EbntaA@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
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: multipart/alternative; boundary=001a11c3640e7ca85b04fe823bfe
Subject: Re: [PHP-DEV] crypt() BC issue
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3640e7ca85b04fe823bfe
Content-Type: text/plain; charset=UTF-8

Hi Anthony,

On Fri, Jul 18, 2014 at 6:56 AM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> > 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.
>

Sounds good to me.


>
> 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.
>

I'll suggest users to use SHA512 raw output as password to
remove 72 chars limitation if it is needed.

<?php
// Use sha512's raw(binary) output
$h = password_hash(hash('sha512', 'my long password', true),
PASSWORD_DEFAULT);

// Verify
$r = password_verify(hash('sha512', 'my long password', true), $h);

var_dump($r); // TRUE
?>


>
> 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".
>

I agree.


> 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....


Raising E_NOTICE for too long password for PASSWORD_BCRYPT
makes sense. I'll add it later.

https://bugs.php.net/bug.php?id=67653

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3640e7ca85b04fe823bfe--