On 16 July 2014 23:16, 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().
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
