Re: Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

From: Date: Thu, 22 Apr 2021 16:04:28 +0000
Subject: Re: Binary (un)safety of password_hash() used with PASSWORD_BCRYPT
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-114104@lists.php.net to get a copy of this message
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.


Thread (15 messages)

« previous php.internals (#114104) next »