Re: Binary (un)safety of password_hash() used with PASSWORD_BCRYPT
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.
-Sara
Thread (15 messages)