Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114106
MIME-Version: 1.0
References: <CAESVnVpCK87GL=+nCvXuT7YS6-QPhF3=8LZSZuAusGFXoT006A@mail.gmail.com>
 <CANUQDCjVfdggrF3wjBCsQ=b_85cq1RhnO_kkVfP3QGubmZhg+g@mail.gmail.com> <CAESVnVr+eOWbizGSAnDwu5+q1rQDe+zcd8r+jUDoRMht768WBA@mail.gmail.com>
In-Reply-To: <CAESVnVr+eOWbizGSAnDwu5+q1rQDe+zcd8r+jUDoRMht768WBA@mail.gmail.com>
Date: Thu, 22 Apr 2021 22:27:25 +0200
Message-ID: <CANUQDCgYhm=32HXa9Msi+UO335a2yk=MYtOL9a5DcpvU6Ct1GA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006a5de605c09582b0"
Subject: Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT
From: me@kelunik.com (Niklas Keller)

--0000000000006a5de605c09582b0
Content-Type: text/plain; charset="UTF-8"

Sara Golemon <pollita@php.net> schrieb am Do., 22. Apr. 2021, 17:27:

> 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


I have links to a library / blog post:

https://github.com/paragonie/password_lock

https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-bcrypt


We're probably better off returning false for verify then instead of
throwing? Hash could hash a random password instead if NUL bytes are
present.

Best,
Niklas




>
> -Sara
>

--0000000000006a5de605c09582b0--