Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86130
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com>
References: <554929FC.1010807@gmx.de>
	<CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com>
Date: Thu, 7 May 2015 08:11:29 +0200
Message-ID: <CAOmo6z8zAQSyauhwbQgmxPhr5M+om15ztuomUjsTwhBGi8w-yA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Christoph Becker <cmbecker69@gmx.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442886c535a4a051577c891
Subject: Re: [PHP-DEV] password_hash() best practices
From: leafnode@gmail.com (Leszek Krupinski)

--f46d0442886c535a4a051577c891
Content-Type: text/plain; charset=UTF-8

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. We do already support it in the
> form of hash_pbkdf2() and people who wish to use this method (e.g. due to
> legal restrictions) can use it through this API - I don't see a reason to
> have it in password_hash(), which should only support the recommended
> default use case.
> <http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf>
>

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).

Also, I'm pro-choice ;) We have an extensible API for password_hash(), and
because people have different needs (like gpu strain in bcrypt or longer
passwords in pbdkf2) we should provide an option for more experienced
users, while having reasonable defaults. Yes, advanced users can use hash
functions directly, but password_* are so nice :)

--Leszek

--f46d0442886c535a4a051577c891--