Sara Golemon <poll...@php.net> schrieb am Fr., 23. Apr. 2021, 00:21: > On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller <m...@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 >
