Re: RFC proposal to deprecate crypt()

On Sun, 20 Feb 2022, 14:17 Tim Düsterhus, <tim@bastelstu.be> wrote: > Hi Steve, > > On 2/20/22 12:44, steve@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. >