Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114111
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>
 <CANUQDCgYhm=32HXa9Msi+UO335a2yk=MYtOL9a5DcpvU6Ct1GA@mail.gmail.com> <CAESVnVqefvhTujS117M8o7Bh=gq7wP2cUjV9quZ3fy9ksRN+qQ@mail.gmail.com>
In-Reply-To: <CAESVnVqefvhTujS117M8o7Bh=gq7wP2cUjV9quZ3fy9ksRN+qQ@mail.gmail.com>
Date: Fri, 23 Apr 2021 21:41:33 +0200
Message-ID: <CANUQDCjkize+xznjgZJUAzE+3a24DRnzK50DuA_FL36tetOK9g@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000041151905c0a8fc41"
Subject: Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT
From: me@kelunik.com (Niklas Keller)

--00000000000041151905c0a8fc41
Content-Type: text/plain; charset="UTF-8"

Sara Golemon <pollita@php.net> schrieb am Fr., 23. Apr. 2021, 00:21:

> On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller <me@kelunik.com> wrote:
> >> 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.
> >
>
> So this library (which I'd need convincing is widely used) doesn't
> actually have any null byte problems.
> Yes, the digest produced by hash(...,true) could have null bytes,
> but it's immediately piped into base64_encode() which papers directly over
> that issue producing only ascii printable output.
>

Scott knows what he's doing, so yes, this library isn't vulnerable nor did
I say that. It is rather an example of pre-encoding. People might remember
the approach incorrectly or have a similar idea themselves and make
mistakes in their own version of such code.

Best,
Niklas

>

--00000000000041151905c0a8fc41--