On Sun, 20 Feb 2022, 14:17 Tim Düsterhus, <t...@bastelstu.be> wrote:
> Hi Steve,
>
> On 2/20/22 12:44, st...@tobtu.com wrote:
>
>
> > If that's the case, you may not know that password_verify() can verify
> all password hashes created by crypt(). The whole point of deprecating and
> finally removing crypt() is that users can no longer create bad password
> hashes. This is a massive gain in security. It's like removing mcrypt which
> removed people's ability to ECB encrypt data. Sure there are very limited
> uses that are secure but 99.9999% are crypto101 errors.
>
> I am maintaining a software that supports a *legacy* password hashing
> algorithm that, for reasons that are not relevant to this discussion,
> performs two passes of BCrypt hashing with the *same* salt:
>
> crypt(crypt('password', '$2a$08$salt'), '$2a$08$salt');
>
> This is not something that can be replicated with password_hash and
> password_verify, because password_hash does not accept an explicit salt
> starting with PHP 8.0 and password_verify does not know about this
> double hashing.
>
> Even though this hashing algorithm is legacy, we need to maintain
> compatibility with that for the foreseeable future to be able to upgrade
> users into the current (password_hash() based) hashes, without them
> needing to reset their passwords.
>
The RFC is about deprecation, not removal.
Set a deadline for your customer (few years?):
* Enable rehashing (you already do)
* Deprecate the old algo internally
* When the deadline is past, drop the old algo: users with an old hash
will have to reset their password
Note that PHP 9 is still far away, so you have time to rehash.
>
