Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86124
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <554929FC.1010807@gmx.de>
References: <554929FC.1010807@gmx.de>
Date: Wed, 6 May 2015 16:00:26 +0200
Message-ID: <CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf0bfc29841b705156a379f
Subject: Re: [PHP-DEV] password_hash() best practices
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bf0bfc29841b705156a379f
Content-Type: text/plain; charset=UTF-8

On Tue, May 5, 2015 at 10:37 PM, Christoph Becker <cmbecker69@gmx.de> wrote:

> Hi everybody!
>
> In issue #64816[1] the OP suggests in the comment from [2015-05-05 04:34
> UTC] that hash_pbkdf2() should be recommended for advanced users, and
> that password_hash() should use PBKDF2 with at least 128,000 rounds.
>

PBKDF2 is known to be weaker than bcrypt for the password hashing usage, as
it is more amenable to implementation on GPUs etc. [1] You can find
estimated hardware costs for PBKDF2 / bcrypt / scrypt with different
settings in the script paper [2, p.14]. PBKDF2 is only stronger than bcrypt
for passwords longer than 72 characters. Note that the scrypt paper assumes
a maximum length of 55 characters, which means the results in the last
column are likely not representing bcrypt correctly.

The primary reason why PBKDF2 is preferable in some contexts (e.g.
government contracts) is that it is approved by NIST in SP 800-132 [3],
although there is some disagreement as to whether this recommendation even
applies for use as a password hashing function, as opposed to usage as a
KDF.

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>

Nikita

[1]:
http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage
[2]: https://www.tarsnap.com/scrypt/scrypt.pdf
[3]: http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf

--047d7bf0bfc29841b705156a379f--