Nikita Popov wrote: > On Tue, May 5, 2015 at 10:37 PM, Christoph Becker <cmbecke...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
