I don't like throwing exceptions for pretty much the same reasons as Nikita
described. This is a rather limited attack vector. It depends either on the
user going out of their way to make their password vulnerable or on the
developer introducing the vulnerability with the use of another function
mangling the passwords. The latter is more likely. In your example, you had
to make the output of MD5 binary to make the function fail. In fact, as far
as I know, browsers strip NUL bytes or convert them to Unicode unknown
character. See spec
https://html.spec.whatwg.org/multipage/parsing.html#parse-error-unexpected-null-character
If developers want to add such measures as part of defence in depth then
the onus is on them to deal with passwords containing NUL bytes. As for
PHP's behaviour, what we could do is strip NUL bytes before hashing with
bcrypt. This would still weaken passwords, but at least wouldn't discard
the rest of the string. We could also add a warning to the manual
explaining that the function is not binary safe.
