> Le 22 avr. 2021 à 03:47, Sara Golemon <poll...@php.net> a écrit :
>
> I have this notion that we've discussed this before, I'm certain I knew
> that bcrypt wasn't binary safe, but someone reminded me that
> password_hash() could be called with null bytes in the password itself and
> that is just SCREAMING to have some safety-rails put on IMO.
>
> So I've thrown together https://github.com/php/php-src/pull/6897 to test
> that argon2 algos behave well (they do!), and modified the bcrypt algo to
> throw an exception if you try to hash a new password containing a null, but
> only warns if you've got a null when running password_verify(). My
> reasoning for the latter is because anyone trying to auth with a null
> character that succeeds does definitely know enough of the password to pass
> by simply not passing the null, so we shouldn't break existing users who
> already have hashes. This only aims to break users who would otherwise be
> able to include a null, because they would have a false sense of security
> having their password truncated and can remedy that in their password
> choosing.
>
> Since this does introduce a (small) break, I'm putting it to the list for
> opinions.
> If nobody objects, I'll merge this (8.1 only) at the end of the month.
>
> -Sara
Hi,
The intention is good, but the solution not so, especially for password_verify.
You introduce a new, subtle way for this function to behave unexpectedly;
because currently, password_verify does not currently trigger warning when
given input of correct type. (Or if it does, it must be documented and fixed,
because it would be a bad thing.)
Also, the warning message you introduced contains “... this hash should be
regenerated using ...”. There is already a dedicated function for conveying
that information in a coder-friendly way, namely `password_needs_rehash()`:
let’s use that (it implies that the default algorithm should be changed).
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
