Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126364
Precedence: bulk
MIME-Version: 1.0
References: <4e41929c-fbd8-44f3-b72d-1b4e6526d001@app.fastmail.com>
 <CAGBsUrdHOfCL3GpUi=7oOSs4G2f2jO5xNsqXTxi6NW78xv8cOQ@mail.gmail.com> <634b8634-5845-40bb-8b7b-758e953db696@app.fastmail.com>
In-Reply-To: <634b8634-5845-40bb-8b7b-758e953db696@app.fastmail.com>
Date: Sun, 9 Feb 2025 21:12:49 +0000
Message-ID: <CAGBsUrf-+Y3XPg0iYAwvDCU9WW8YUOiK3EhyOWckYG8qgSr0kA@mail.gmail.com>
Subject: Re: [PHP-DEV] bcrypt warning on long passwords
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tekiela246@gmail.com (Kamil Tekiela)

On Sun, 9 Feb 2025 at 20:58, Rob Landers <rob@bottled.codes> wrote:
> I fully agree with you, however it is also the default password hashing a=
lgorithm. People 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 should probably at least warn people when they are using it wrong. The=
y can then do whatever they want (ignore it, migrate to a different hashing=
 algorithm, turn it into an exception, or adjust their inputs).

My point is that passing a password longer than 72 bytes to
password_hash is not wrong. The bcrypt algorithm will work fine and
just ignore the unnecessary bytes. It is perfectly normal to let users
provide longer passwords and pass them to password_hash unrestricted.

What is wrong is when people use password_hash for
non-password-related stuff like in the linked article. The problem
wasn't that password_hash didn't warn them, but that they prepended
the password with non-password information. I expect an oven to cook a
chicken, but if I first fill the oven with water, I'd be insane
expecting it to work the same way.