Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117105
Date: Mon, 21 Feb 2022 10:43:55 -0600 (CST)
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
	Marco Pivetta <ocramius@gmail.com>,
	Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Message-ID: <1846031176.2904638.1645461835527@email.ionos.com>
In-Reply-To: <b52c5f52-3295-7792-1897-c170bb132331@bastelstu.be>
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>
 <CADyq6sLWRfD2DJwRNWmX=s7rbA2Rs+Agu9tsW9mLQbCeJ27vwA@mail.gmail.com>
 <40015164-ac0c-336d-c7d6-c4766d6caff8@gmail.com>
 <CADyq6s+e_Jkwg1UoGS_e23=6FciRB2-d8q_NxkREMt45f=vs8g@mail.gmail.com>
 <b52c5f52-3295-7792-1897-c170bb132331@bastelstu.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt()
From: steve@tobtu.com

If crypt() is removed, you can still use password_verify() to verify all th=
e password hashes created by crypt(). The only thing you lose is creating t=
hose bad password hashes. Which can be done in userland because most people=
 aren't changing their passwords daily. So it will run that slow userland c=
ode infrequently. This will not help the nested bcrypt example. Well beside=
s the last bcrypt call can be password_verify():

password_verify(crypt($password, $hash), $hash);


> On 02/21/2022 4:10 AM Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
>=20
> =20
> Hi Marco
>=20
> On 2/21/22 10:15, Marco Pivetta wrote:
> >> If it's not going to be removed, what's the point of annoying people
> >> with deprecation warnings (that they would patch out/silence anyway)?
> >>
> >=20
> > Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at
> > some point.
>=20
> In contrast to other deprecations (e.g. the utf8_encode/decode currently=
=20
> discussed), deprecating and ultimately removing crypt() results in an=20
> actual loss of functionality.
>=20
> Even if we leave out that home-grown nested BCrypt hashing out of the=20
> picture, crypt() allows one to interoperate with non-PHP-software that=20
> does not support BCrypt, but supports the SHA-X variants. I already=20
> mentioned Dovecot as an example, but BCrypt support in glibc in general=
=20
> is something that was added only somewhat recently (and I'm not even=20
> sure if that's only for Debian-based systems or generally available [1]).
>=20
> Yes, users should just use password_hash() if they need to hash=20
> passwords. Yes, the documentation for crypt() should more prominently=20
> point to password_hash() as the better alternative. But if crypt()'s=20
> features are what you need, then alternatives to crypt() (e.g. a=20
> userland implementation or FFI) certainly are going to be even worse.
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=3D16814
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php