Hi Anthony, I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > 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 >> > I wrote "Use of <function>crypt</function> is deprecated." not "crypt() is deprecated". I didn't mean crypt() function deprecation. If it's confusing, I don't mind at all to rewrite it. BTW, what part is wrong? It seems we have misunderstanding each other, but the basis is the same, I suppose. - crypt() will remain - User/developer should use password_*() - It's not good idea to have PHP own crypt() The differences are E_NOTICE and workaround, it seems. IMO, password_hash() must raise E_NOTICE for too long password. Truncation without error is not an option for me. People write stupid code without internal knowledge. Adding fixed salt was common since crypt() was not good enough used to be. In addition, maximum password length is not decided by us, but decided by app developers. Therefore, we are better to provide/explain workaround for password_hash() limitation. Prehash in PHP is not an option as we don't want PHP only crypt(). Prehash by developer is acceptable workaround for me. As you know, chars that are used in password is limited. Some developers even allow UTF-8 for password, structured encoding could reduce total number of bits in password hash with limited password length. Prehash with raw SHA512 will give us adequate data for PASSWORD_BCRYPT hashing regardless of password length. Prehash ruins password_*() flexibility for sure, but there is workaround also. Developer may use timestamp to check new hash (e.g. 1024 bits hash, etc) should be used or not. If we don't want such workarounds, we may enable SHA512 hash for password_hash() for those who don't want password length limit. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
