Hi Anthony,

On Fri, Jul 18, 2014 at 6:56 AM, Anthony Ferrara <ircmax...@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
yohg...@ohgaki.net

Reply via email to