Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103326
MIME-Version: 1.0
References: <CAESVnVq-oQreEyNDQZPWJ+fxuXs_66WWBTywRii7AFEFjqxBNQ@mail.gmail.com>
 <CALKiJKrhB9pKtdF=PdBwrJB-81QLCGtr1TKF6rQ0p8XtGhFrrA@mail.gmail.com>
 <CAESVnVpXjvR2-3n6AdSA+TwzsGEEeAD0L2dH18wiDtHnwE7uHA@mail.gmail.com> <CALKiJKqxgFd=fQvapDrX3tJLtuEkEXk-qHwv=XrNfM5OURROHg@mail.gmail.com>
In-Reply-To: <CALKiJKqxgFd=fQvapDrX3tJLtuEkEXk-qHwv=XrNfM5OURROHg@mail.gmail.com>
Date: Thu, 18 Oct 2018 08:55:25 -0500
Message-ID: <CAESVnVq6xDk1CmVvHNCcxyLQMmDz3CnqGBvNDJDdZYzTaVZJvQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Password Digest Registry
From: pollita@php.net (Sara Golemon)

On Tue, Oct 16, 2018 at 11:54 AM Rowan Collins <rowan.collins@gmail.com> wr=
ote:
> On Tue, 16 Oct 2018 at 16:35, Sara Golemon <pollita@php.net> wrote:
>> On Tue, Oct 16, 2018 at 8:43 AM Rowan Collins <rowan.collins@gmail.com> =
wrote:
>> > As I understand it, the purpose of the $foo$ syntax is to uniquely ide=
ntify
>> > each algorithm, so would it make sense to pass the prefix string to th=
e
>> > register call, and maintain a lookup table internally of prefix =3D> h=
andler?
>> >
>> If that's an assumption we can definitely make, then absolutely, that
>> simplifies a lot of the design.  When preparing this I wasn't 100%
>> confident that this would hold true (maybe
>> $foo${hashspecificstuff},v=3D1 is different from
>> $foo${hashspecificstuff},v=3D2), and I didn't want to create a problem
>> for future us.  But I suppose we can always extend the protocol if it
>> comes to that.
>
> I think encoding that assumption in PHP is following the general consensu=
s, and in the absence of a stronger standard we're not obliged to follow an=
 implementation that varies from that consensus anyway. In other words, if =
someone implements MyAwesomeHash as a C library that doesn't use a unique p=
refix of the appropriate form, the PHP wrapper can always prepend $MyAwesom=
eHash$ to the C library's output, and strip it off again when verifying.
>
Thanks for the research!  I was hoping this was the case, I just
hadn't managed to confirm it.

Unfortunately, I just sat down to implement it and noticed that we
have explicit test cases which verify that only hashes with a prefix
of "$2y" *and* a length of precisely 60 are identified as bcrypt.  So
either we need to loosen that check (I'm trying to avoid BC breaks
here), or we create additional identification logic.

My personal take is that, given a preference for maintaining BC, we
should should keep a more generalized ident callback, even though the
fixed prefix is cleaner and more expedient.  If we're willing to break
some BC, then I'd *also* vote in favor of making the algo identifiers
be strings instead of numbers.

-Sara