Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126363
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 09 Feb 2025 21:57:51 +0100
To: "Kamil Tekiela" <tekiela246@gmail.com>
Cc: internals@lists.php.net
Message-ID: <634b8634-5845-40bb-8b7b-758e953db696@app.fastmail.com>
In-Reply-To: 
 <CAGBsUrdHOfCL3GpUi=7oOSs4G2f2jO5xNsqXTxi6NW78xv8cOQ@mail.gmail.com>
References: <4e41929c-fbd8-44f3-b72d-1b4e6526d001@app.fastmail.com>
 <CAGBsUrdHOfCL3GpUi=7oOSs4G2f2jO5xNsqXTxi6NW78xv8cOQ@mail.gmail.com>
Subject: Re: [PHP-DEV] bcrypt warning on long passwords
Content-Type: multipart/alternative;
 boundary=d443af81d2be416e965b4e225b5cc3fc
From: rob@bottled.codes ("Rob Landers")

--d443af81d2be416e965b4e225b5cc3fc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Feb 9, 2025, at 16:20, Kamil Tekiela wrote:
> Hi,
>=20
> I would say that this is a pretty bad idea. 72 bytes of entropy are
> quite a lot for *PASSWORDS*. Even if some users use a pass phrase
> longer than that, the first 72 bytes are enough to provide sufficient
> security. People who use it for other stuff, like in the linked
> article, are only to blame themselves. They use the wrong tool for the
> job. The limitation of bcrypt is very clearly documented[1].
>=20
> Triggering a warning at runtime wouldn't be useful to the developer.
> To avoid such a warning they would need to either reject passwords
> longer than 72 bytes or truncate them before passing it to
> password_hash. Both approaches provide no additional security or any
> other value. That would only annoy either the developers or the users.
>=20
> Letting bcrypt use only the first 72 bytes is a very safe and easy
> solution. No need to overcomplicate it.
>=20
> Regards,
> Kamil
>=20
> [1]: https://www.php.net/manual/en/function.password-hash.php#refsect1=
-function.password-hash-parameters
>=20

I fully agree with you, however it is also the default password hashing =
algorithm. People may not read the docs and assume a generic implementat=
ion that isn=E2=80=99t constrained. Since it is the default and has cons=
traints, we should probably at least warn people when they are using it =
wrong. They can then do whatever they want (ignore it, migrate to a diff=
erent hashing algorithm, turn it into an exception, or adjust their inpu=
ts).

=E2=80=94 Rob
--d443af81d2be416e965b4e225b5cc3fc
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Sun, Feb 9, 2025, at 16:20, Kamil Tekiela wrote:<br></=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi,<br></div><di=
v><br></div><div>I would say that this is a pretty bad idea. 72 bytes of=
 entropy are<br></div><div>quite a lot for *PASSWORDS*. Even if some use=
rs use a pass phrase<br></div><div>longer than that, the first 72 bytes =
are enough to provide sufficient<br></div><div>security. People who use =
it for other stuff, like in the linked<br></div><div>article, are only t=
o blame themselves. They use the wrong tool for the<br></div><div>job. T=
he limitation of bcrypt is very clearly documented[1].<br></div><div><br=
></div><div>Triggering a warning at runtime wouldn't be useful to the de=
veloper.<br></div><div>To avoid such a warning they would need to either=
 reject passwords<br></div><div>longer than 72 bytes or truncate them be=
fore passing it to<br></div><div>password_hash. Both approaches provide =
no additional security or any<br></div><div>other value. That would only=
 annoy either the developers or the users.<br></div><div><br></div><div>=
Letting bcrypt use only the first 72 bytes is a very safe and easy<br></=
div><div>solution. No need to overcomplicate it.<br></div><div><br></div=
><div>Regards,<br></div><div>Kamil<br></div><div><br></div><div>[1]:&nbs=
p;<a href=3D"https://www.php.net/manual/en/function.password-hash.php#re=
fsect1-function.password-hash-parameters">https://www.php.net/manual/en/=
function.password-hash.php#refsect1-function.password-hash-parameters</a=
><br></div><div><br></div></blockquote><div><br></div><div>I fully agree=
 with you, however it is also the default password hashing algorithm. Pe=
ople may not read the docs and assume a generic implementation that isn=E2=
=80=99t constrained. Since it is the default and has constraints, we sho=
uld probably at least warn people when they are using it wrong. They can=
 then do whatever they want (ignore it, migrate to a different hashing a=
lgorithm, turn it into an exception, or adjust their inputs).</div><div>=
<br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--d443af81d2be416e965b4e225b5cc3fc--