Re: password_hash() best practices

Leszek Krupinski wrote on 07/05/2015 07:11:

On Wed, May 6, 2015 at 4:00 PM, Nikita Popov <nikita.ppv@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]