Re: password_hash() best practices
| From: | Christoph Becker | Date: | Wed, 06 May 2015 18:57:16 +0000 |
| Subject: | Re: password_hash() best practices | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-86125@lists.php.net to get a copy of this message | ||
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