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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
