On Tue, May 5, 2015 at 10:37 PM, Christoph Becker <cmbecke...@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
