Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117076
MIME-Version: 1.0
References: <5983302.2649742.1645319015766@email.ionos.com>
 <6238bf00-011e-35cc-d84b-4082b4f05099@gmail.com> <497325306.1564942.1645357444018@email.ionos.com>
 <3c6871ca-589d-6812-800c-a3b9ad6bb575@bastelstu.be>
In-Reply-To: <3c6871ca-589d-6812-800c-a3b9ad6bb575@bastelstu.be>
Date: Sun, 20 Feb 2022 14:24:16 +0100
Message-ID: <CADyq6sLWRfD2DJwRNWmX=s7rbA2Rs+Agu9tsW9mLQbCeJ27vwA@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: steve@tobtu.com, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000df74805d8730973"
Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt()
From: ocramius@gmail.com (Marco Pivetta)

--0000000000000df74805d8730973
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 20 Feb 2022, 14:17 Tim D=C3=BCsterhus, <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 an=
d
> 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 whi=
ch
> 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.

>

--0000000000000df74805d8730973--