Sara Golemon <poll...@php.net> schrieb am Do., 22. Apr. 2021, 17:27: > On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller <m...@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 >
