Yasuo > I'll suggest users to use SHA512 raw output as password to > remove 72 chars limitation if it is needed.
Then you either misunderstood what I was saying, or completely ignored 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 Please, don't change anything without first proposing an RFC so that sufficient discussion can occur. Literally every single person in this thread has disagreed with you, yet you want to go ahead and make changes. It's not saying that you are wrong, but that discussion needs to happen before any changes to security sensitive code and documentation. Also, Deprecating crypt() without first discussing it (and having an RFC to vote on) is not cool (and has been reverted): http://svn.php.net/viewvc/phpdoc/en/trunk/reference/strings/functions/crypt.xml?r1=333973&r2=334296 > Generally speaking, it would not be serious issue. 72 bytes constant prefix > would > not be used most likely. Correct. So if it's not a serious issue, why are we talking about adding serious warnings to documentation pages (big red boxes), and notices and pre-hashing? > However, bug like this in "authentication" code must be detected and > fixed. It's not a bug. It's by design. You could argue if it's a good design or not, but it's very much by design. > If password should be truncated, it should be truncated by app developers > explicitly and > notified users that their password had been truncated. IMHO. We disagree. So rather than just committing changes, why not draft up an RFC with your suggestions, which can be discussed and voted upon? > There's already a notice about this in the password_hash() docs, one that > almost looks like is designed to scare users, which is bad. Throwing an > E_NOTICE will cause more problems than it would supposedly solve. I agree 100%. It's on my list of things to do to "clean up" that warning, to word it to be less scary. And I agree 100% on the notice side as well. > Application developers should just state this limitation on their > registration/password change pages, anything else is pointless. I don't think so. If the end user enters a 72 character+ password, the chances of a collision because of the truncation are so small that it's not worth worrying about. However, it's worth documenting, as what you don't want is people inventing their own crypto by prefixing their own secret: password_hash(hash('sha512', SECRET_KEY) . $password, PASSWORD_DEFAULT) Which would then always produce the same hash (since the sha512 hash is 128 bytes long, truncation would happen too early). We should be educating people to avoid their own crypto. That was the entire point of the password_hash APIs. Make it so simple that it's difficult to screw up. Yet people will always find a way. The only way to solve that problem is education. And adding big red boxes isn't education. It's fear. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
