4 ms·

Seems bizarre to me that hash_pbkdf2() has also been accepted, was authored by the same author, and provides for "better"* hashing than bcrypt(), and yet isn't

Seems bizarre to me that hash_pbkdf2() has also been accepted, was authored by the same author, and provides for "better"* hashing than bcrypt(), and yet isn't the PASSWORD_DEFAULT or, indeed, even an option for the secure password hashing algorithm. wtf? * In the crypto community, "better" usually refers to how long an algorithm has been around, how well reviewed & used it is, and how bug-free it's been. Looking at all of these, PBKDF2 is clearly superior to bcrypt, which has had significant bugs, isn't as widely deployed, etc. https://wiki.php.net/rfc/hash_pbkdf2 https://wiki.php.net/rfc/hash_pbkdf2 http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2

JoachimSchipper 14y ago
[EDIT: tptacek is right. Listen to tptacek.] PBKDF2 isn't necessarily better than bcrypt. But yes, it's a good choice.
- tptacek 14y ago
  PBKDF2 is objectively worse than bcrypt, but the difference between them isn't meaningful. The only meaningful choice in password hashes is between PBKDF2/bcrypt and scrypt, which is hardened against gate-level-optimized attacks.
- pbsd 14y ago
  They're not comparable: PBKDF2 is a mode of operation, bcrypt is an actual instantiation of a password hashing scheme. Saying one is (objectively) better than the other is meaningless, or at least very misleading.
tptacek 14y ago
None of what you've said about PBKDF2 vs. bcrypt is true. PBKDF2 is inferior to bcrypt (see Colin's scrypt paper for details), has never had a published design flaw, and is less widely deployed than PBKDF2 (many people think they're "doing PBKDF2" when they iterate a hash function 1000 times). Having said all that, who cares? Pick one or the other. I'd have exactly the same positive comment regarding the new PHP interface if they had used PBKDF2 with a sane cost. The only harmful decision you can make regarding password hashes is to wait to implement them in order to pick the "best" one.
- onethumb 14y ago
  bcrypt uses Blowfish as it's block cipher, so an issue with blowfish is an issue with bcrypt. There have been Blowfish problems, like this charset issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 bcrypt also weakens on long passphrases, since it only uses 55 chars of input. I'm certainly not suggesting that people not use bcrypt, I'm just surprised that it's the only option.
  - tptacek 14y ago
    This is a string of non sequiturs posing as an argument.
  - Firehed 14y ago
    Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming you have hash_hmac easily available). So if there's a problem found with sha256 or whatever hashing function you choose it use it with, then it too has a problem. That's not to knock PBKDF2 - I'm just pointing out that both have flaws, and that people should use the right tool for the job. The "KDF" in "PBKDF2" stands for Key Derivation Function; i.e., it's for deriving a(n encryption) key. bcrypt exists basically for the sole purpose of password storage. In practical terms, it's more obvious how to use bcrypt's work factor as computers speed up than PBKDF2's iteration count, although either is quite suitable for the job. It's also easier to rehash bcrypt-stored passwords when upping your work factor - the old version will still verify, just check for $WF$ not matching your current work factor. PBKDF2 requires a bit more logic since you have to rehash with a different iteration count and do a second comparison, which conceivably also opens you up to a timing attack unless you're very careful about how you do it. To me, it's a matter of what a tool was designed for. Given that I have the right tool for the job, why use something that's designed for something else even though it works quite well?
ircmaxell 14y ago
The main reason that I didn't provide bindings to PBKDF2 is that I didn't want to create a new output format. There's presently no crypt(3) format specified for PBKDF2. So that means that I would need to invent one. That's not something I'm willing to do for a core language feature. Additionally, pbkdf2 is actually slightly weaker than bcrypt (partially due to the higher memory requirements of the later, 32kb vs < 1kb). So without a strong reason for including it, it wasn't included. However, the API is designed to be extendable. When scrypt gets bindings to crypt(3), it'll be made available. If PBKDF2 gets bindings, it'll be made available. If a new and stronger algorithm is made, it'll be made available (but not default for quite some time). But I personally am not willing to go out on a limb and create a new cryptographic specification for this project. And that's what it would have taken to put pbkdf2 into it. Hence, why it's not there...
- onethumb 14y ago
  This is a great argument. Thanks for the clarification. Storing the salt, algorithm, strength, etc in some standard format would certainly be required for a simplified API like this.

JoachimSchipper 14y ago

[EDIT: tptacek is right. Listen to tptacek.] PBKDF2 isn't necessarily better than bcrypt. But yes, it's a good choice.

tptacek 14y ago
PBKDF2 is objectively worse than bcrypt, but the difference between them isn't meaningful. The only meaningful choice in password hashes is between PBKDF2/bcrypt and scrypt, which is hardened against gate-level-optimized attacks.
pbsd 14y ago
They're not comparable: PBKDF2 is a mode of operation, bcrypt is an actual instantiation of a password hashing scheme. Saying one is (objectively) better than the other is meaningless, or at least very misleading.

tptacek 14y ago

None of what you've said about PBKDF2 vs. bcrypt is true. PBKDF2 is inferior to bcrypt (see Colin's scrypt paper for details), has never had a published design flaw, and is less widely deployed than PBKDF2 (many people think they're "doing PBKDF2" when they iterate a hash function 1000 times). Having said all that, who cares? Pick one or the other. I'd have exactly the same positive comment regarding the new PHP interface if they had used PBKDF2 with a sane cost. The only harmful decision you can make regarding password hashes is to wait to implement them in order to pick the "best" one.

onethumb 14y ago
bcrypt uses Blowfish as it's block cipher, so an issue with blowfish is an issue with bcrypt. There have been Blowfish problems, like this charset issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 bcrypt also weakens on long passphrases, since it only uses 55 chars of input. I'm certainly not suggesting that people not use bcrypt, I'm just surprised that it's the only option.
- tptacek 14y ago
  This is a string of non sequiturs posing as an argument.
- Firehed 14y ago
  Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming you have hash_hmac easily available). So if there's a problem found with sha256 or whatever hashing function you choose it use it with, then it too has a problem. That's not to knock PBKDF2 - I'm just pointing out that both have flaws, and that people should use the right tool for the job. The "KDF" in "PBKDF2" stands for Key Derivation Function; i.e., it's for deriving a(n encryption) key. bcrypt exists basically for the sole purpose of password storage. In practical terms, it's more obvious how to use bcrypt's work factor as computers speed up than PBKDF2's iteration count, although either is quite suitable for the job. It's also easier to rehash bcrypt-stored passwords when upping your work factor - the old version will still verify, just check for $WF$ not matching your current work factor. PBKDF2 requires a bit more logic since you have to rehash with a different iteration count and do a second comparison, which conceivably also opens you up to a timing attack unless you're very careful about how you do it. To me, it's a matter of what a tool was designed for. Given that I have the right tool for the job, why use something that's designed for something else even though it works quite well?

ircmaxell 14y ago

The main reason that I didn't provide bindings to PBKDF2 is that I didn't want to create a new output format. There's presently no crypt(3) format specified for PBKDF2. So that means that I would need to invent one. That's not something I'm willing to do for a core language feature. Additionally, pbkdf2 is actually slightly weaker than bcrypt (partially due to the higher memory requirements of the later, 32kb vs < 1kb). So without a strong reason for including it, it wasn't included. However, the API is designed to be extendable. When scrypt gets bindings to crypt(3), it'll be made available. If PBKDF2 gets bindings, it'll be made available. If a new and stronger algorithm is made, it'll be made available (but not default for quite some time). But I personally am not willing to go out on a limb and create a new cryptographic specification for this project. And that's what it would have taken to put pbkdf2 into it. Hence, why it's not there...

onethumb 14y ago
This is a great argument. Thanks for the clarification. Storing the salt, algorithm, strength, etc in some standard format would certainly be required for a simplified API like this.