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