php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #64816 CRYPT_BLOWFISH is not better than PBKDF2
Submitted: 2013-05-11 00:02 UTC Modified: 2015-05-17 04:22 UTC
Votes:9
Avg. Score:4.0 ± 0.9
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:2 (50.0%)
From: nenolod at dereferenced dot org Assigned:
Status: No Feedback Package: hash related
PHP Version: 5.5.0RC1 OS: N/A
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
49 - 30 = ?
Subscribe to this entry?

 
 [2013-05-11 00:02 UTC] nenolod at dereferenced dot org
Description:
------------
---
From manual page: http://www.php.net/function.hash-pbkdf2#refsect1-function.hash-pbkdf2-notes
---

CRYPT_BLOWFISH has a limit of 76 characters maximum.  PBKDF2 has no limit, and when used with an HMAC function like sha256 or sha512 is vastly more complex to crack.

Please consider removing this from the documentation as it recommends a poor security practise as 'superior'.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-28 06:57 UTC] yohgaki@php.net
-Status: Open +Status: Analyzed
 [2013-06-28 06:57 UTC] yohgaki@php.net
From the manual
==================
Caution
The PBKDF2 method can be used for hashing passwords for storage (it is NIST 
approved for that use). However, it should be noted that CRYPT_BLOWFISH is 
better suited for password storage and should be used instead via crypt().
==================

This is too much. There are several problems.

1. crypt() is not encouraged, password_hash() is. (PHP 5.5>=)
2. PHP 5.5 users are encouraged to use password_hash() since it allows to 
upgrade hashing algorithm by upgrading PHP. (i.e. automatically updates 
algorithm) 
3. Both password_hash() and hash_pbkdf2() are good enough if users used them 
with correct parameters. 

Note that correct usage is important for robust security. RFC 2898 suggest 1000+ 
rounds and NIST suggests several thousands rounds with SHA2 hashing. However, 
these number may consider too few with current technology.

http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-
using-pkbdf2-sha256

It recommends tens of thousands rounds with SHA2 hash.

Anyway, both password_hash(), which uses crypt+blowfish internally, and 
hash_pbkdf2() good enough if users set at least 10000 rounds with SHA2 hash. (I 
would recommend 20000+, though)

I know there are number of weaknesses of blowfish have been reported, but it 
wouldn't be a problem with password length longer than 8 chars (I would 
recommend at least 10. 12+ is better)

Current password_hash() uses a little few rounds(2^10 = 1024). Since hash 
computation execution efficiency is differ from SHA2, blowfish requires less 
rounds and 1024 is acceptable, IMO. (I would suggest 2^12 or more, though)

Anyway, many users don't have clue about password hashing and current 
documentation cannot consider correct. Doc should be updated.
 [2015-05-04 18:03 UTC] cmb@php.net
-Status: Analyzed +Status: Feedback -Package: Documentation problem +Package: hash related
 [2015-05-04 18:03 UTC] cmb@php.net
The respective info in the manual has been changed in the
meantime:

| The PBKDF2 method can be used for hashing passwords for storage.
| However, it should be noted that password_hash() or crypt() with
| CRYPT_BLOWFISH are better suited for password storage.

Is that sufficient?
 [2015-05-05 04:34 UTC] nenolod at dereferenced dot org
-Status: Feedback +Status: Open
 [2015-05-05 04:34 UTC] nenolod at dereferenced dot org
It is not sufficient because it is wrong.  Recommending a dubious homegrown password hashing solution instead of a standard one (PBKDF2) is also dubious in and of itself, even if the cryptographic primitives are correct.

The text should recommend that the PBKDF2 functions be used by "advanced" users (since the cryptographic primitives used are configurable), and password_hash() should use PBKDF2 with at least 128,000 rounds or more which is standard practice, *not* CRYPT_BLOWFISH.

PHP is an overgrown templating engine not a cryptography research toolkit, it should be using standardized best practices for password security.
 [2015-05-06 19:37 UTC] cmb@php.net
-Status: Open +Status: Feedback
 [2015-05-06 19:37 UTC] cmb@php.net
It should be noted that crypt(3) and password_hash(), which is
based on crypt(3), are no "dubios homegrown password hashing
solutions", but rather widely used.

The fact that PBKDF2 is recommended by NIST as "Password-Based Key
Derivation" function[1] is indisputable, but it might be
disputable that it is equally well suited for hashing passwords.
According to a StackExchange thread[2], bcrypt is somewhat better
suited for password hashing than PBKDF2, and according to the
scrypt paper[3], table 1 on page 14, bcrypt is harder to crack
then PBKDF2 for typical password lengths.

Can you point to any references to back your claim that bcrypt
should not be used for password hashing, and that PBKDF2 is
superior for this purpose?

Anyway, using PBKDF2 for password_hash() is probably not the best
idea, as there is no standardized crypt-compatible format for this
algorithm.

[1] <http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf>
[2] <http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage>
[3] <https://www.tarsnap.com/scrypt/scrypt.pdf>
 [2015-05-17 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 08:01:28 2024 UTC