Re: crypt() BC issue

On 16 July 2014 23:16, 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(). Whoa. Don't put too much stock in that — I think I made that up out of whole cloth while trying to get _something_ into the manual for one of the early alpha releases of 5.5, and it wasn't intended as a restrictive statement. > 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. The original RFC specified that both crypt() and password_hash() hashes were accepted here, and that's probably what the documentation should say too. Adam