On Wed, May 6, 2015 at 4:00 PM, Nikita Popov <nikita....@gmail.com> wrote:
> 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> > That's true that there's no support for pbkdf2 in crypt. On the other hand, the RFC for password_hash stated: > These hashing APIs will initially be thin wrappers around *crypt()* to allow for automatic salt generation and better error checking. It says "initially" - that's why I understood that in the future we can diverge from crypt in situations when there's a great new hash we would like to use, but it's not supported by crypt (yet or at all). Also, I'm pro-choice ;) We have an extensible API for password_hash(), and because people have different needs (like gpu strain in bcrypt or longer passwords in pbdkf2) we should provide an option for more experienced users, while having reasonable defaults. Yes, advanced users can use hash functions directly, but password_* are so nice :) --Leszek
