> Exactly, and my proposal aims to throw a ValueError in those cases, > indicating that it is a programming error to pass anything other than > password. The tradeoff is that actual passwords longer than 72 bytes are no > longer supported. I think that is acceptable.
The function signature already says it will accept a `string` value, and it is already working under this contract. Limiting it to 72 bytes does not ensure the passed string is a password, and it is merely an implementation detail for bcrypt. The php.net manual page for `password_hash` also already mentions the 72-byte truncation behavior. Passing an invalid hashing algorithm, unsupported algorithm options, RNG failures, etc., are indeed programmer/program errors, and it already throws hard exceptions/errors in those cases. I wouldn't also characterize the two vulnerabilities mentioned in the RFC (in other software) as related. In PHP, the salt is now (PHP 7+) always generated automatically, and the password_hash() output is not limited to a certain length. While I agree that vulnerable software could be written around bcrypt's 72-byte behavior, it would not be a strong relation to PHP. Thank you, Ayesh.
