Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114103
MIME-Version: 1.0
References: <CAESVnVpCK87GL=+nCvXuT7YS6-QPhF3=8LZSZuAusGFXoT006A@mail.gmail.com>
 <CANUQDCjVfdggrF3wjBCsQ=b_85cq1RhnO_kkVfP3QGubmZhg+g@mail.gmail.com>
In-Reply-To: <CANUQDCjVfdggrF3wjBCsQ=b_85cq1RhnO_kkVfP3QGubmZhg+g@mail.gmail.com>
Date: Thu, 22 Apr 2021 10:27:27 -0500
Message-ID: <CAESVnVr+eOWbizGSAnDwu5+q1rQDe+zcd8r+jUDoRMht768WBA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000be7b3c05c0915102"
Subject: Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT
From: pollita@php.net (Sara Golemon)

--000000000000be7b3c05c0915102
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller <me@kelunik.com> wrote:
> Thank you for your work. I think this is a really good safety check to
have. I'd however go a step further and also throw on NUL in
password_verify.
>
> You seem to assume that NUL bytes as input come from the end user, but I
think it's more likely the developer uses a hash function with raw output
as a pre-encoding, for reasons such as bringing long passwords below the
bcrypt character limit.
>

I definitely am making the assumption you describe and it slightly
horrifies me to learn that people are using a pre-digest (though I can
understand why they would; ostensibly this should improve significance of
the input bits).

Do you have a link to places where frameworks are doing this?  I built a
contrived example which I think summarizes the behavior you described here:
https://3v4l.org/6tunp

-Sara

--000000000000be7b3c05c0915102--