Hi Tjerk, On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters <tjerk.meest...@gmail.com> wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> Hi Tjerk, >> >> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters < >> tjerk.meest...@gmail.com> wrote: >> >>> Why should `password_verify()` work on a hash that wasn't generated with >>> `password_hash()`? The fact that it uses `crypt()` internally should not >>> leak outside of its API, imho. >> >> >> password_*() is designed as crypt() wrapper and this fact is documented >> since it was released. >> >> Obsolete password hash is easy to verify with password_needs_rehash(). >> Developers can check password database easily with >> password_needs_rehash(). >> > > The documentation states that the `hash` argument to both > `password_needs_rehash()` and `password_verify()` is: > > hash - A hash created by password_hash(). > > Passing a value from your own crypt() implementation may work, but that > shouldn't be relied upon. I certainly wouldn't classify it as a problem > that should be fixed in the password api > It's easier to change crypt() behavior, since password_*() is crypt() wrapper. Are we going to relax the crypt() restriction permanently? It's ok for me. Users are better to use password_*() anyway. We must remove 72 bytes restriction in password_*() ASAP, though. i.e. blowfish truncates password longer than 72 bytes. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
