Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
Message-ID: <554A640C.6030002@gmx.de>
Date: Wed, 06 May 2015 20:57:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <554929FC.1010807@gmx.de> <CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com>
In-Reply-To: <CAF+90c8R_Ny9yjPsqTqVw_zY6JW7vf5Y6DoyYAb5_Gvanf9FCw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] password_hash() best practices
From: cmbecker69@gmx.de (Christoph Becker)

Nikita Popov wrote:

> On Tue, May 5, 2015 at 10:37 PM, Christoph Becker <cmbecker69@gmx.de> wrote:
>
>> 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.

Thanks, Nikita, for the detailed explanation and the links.  Sounds very
convincing to me. :)

> 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.

Thanks for the explanation.  I agree that it doesn't make sense to add a
non-standard crypt format for PBKDF2.

> [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

-- 
Christoph M. Becker