Re: crypt() BC issue

Hi Tjerk, On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters <tjerk.meesters@gmail.com> wrote: > On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > >> Hi Tjerk, >> >> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters < >> tjerk.meesters@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 yohgaki@ohgaki.net