Leszek Krupinski wrote on 07/05/2015 07:11:
On Wed, May 6, 2015 at 4:00 PM, Nikita Popov <nikita....@gmail.com> wrote:
It should be further noted that there is no standardized crypt() format for
PBKDF2 and password_hash() is a crypt-compatible API. As such supporting
PBKDF2 there would be very problematic.
That's true that there's no support for pbkdf2 in crypt. On the other hand,
the RFC for password_hash stated:
These hashing APIs will initially be thin wrappers around *crypt()* to
allow for automatic salt generation and better error checking.
It says "initially" - that's why I understood that in the future we can
diverge from crypt in situations when there's a great new hash we would
like to use, but it's not supported by crypt (yet or at all).
Notwithstanding the merits of using it in this case, I wonder if there's
a possibility to invent a syntax recognised by password_hash which is an
explicit extension of what crypt uses, and is guaranteed not to collide,
kind of like the "X-" header prefix in HTTP.
If a "standard" format for the same algorithm was added in future,
password_needs_rehash could return true for the deprecated interim
format, allowing a smooth transition. (If you explicitly chose PBKDF2,
you would still need to call that function to allow for increases in the
cost parameter.)
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
