Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
Message-ID: <554B849D.2040308@gmail.com>
Date: Thu, 07 May 2015 16:28:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <554929FC.1010807@gmx.de>	<CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com> <CAOmo6z8zAQSyauhwbQgmxPhr5M+om15ztuomUjsTwhBGi8w-yA@mail.gmail.com>
In-Reply-To: <CAOmo6z8zAQSyauhwbQgmxPhr5M+om15ztuomUjsTwhBGi8w-yA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] password_hash() best practices
From: rowan.collins@gmail.com (Rowan Collins)

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]