|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #64537 Key is truncated for password_hash/crypt
Submitted: 2013-03-28 11:53 UTC Modified: 2017-01-16 14:41 UTC
From: lekensteyn at gmail dot com Assigned: ircmaxell (profile)
Status: Closed Package: *Encryption and hash functions
PHP Version: 5.5.0beta1 OS: Linux x86_64
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: lekensteyn at gmail dot com
New email:
PHP Version: OS:


 [2013-03-28 11:53 UTC] lekensteyn at gmail dot com
While using password_hash() and password_verify() (using the compat library from ircmaxwell[0] on PHP 5.4), I noticed that two passwords passed the test while those are really different.

It turns out that blowfish limits the length of the key to 72 bytes which is also stated in the modified manual page of crypt(3) [1]. This limitation is not documented anywhere and poses a risk to those who assume that the key length is unlimited.

Documentation that must be updated:
- crypt
- password_hash and password_verify
- hash_pbkdf2 (since you recommend using crypt+bf instead, it should also tell the difference)

Affected versions:
- 5.3.10-1ubuntu3.6 (Ubuntu 12.04 x86_64)
- 5.4.13-2 (Arch Linux x86_64)
- 5.5.0beta2 (Arch Linux x86_64, built with ./configure --without-pear)

I marked 5.5.0beta1 as affected as there is no beta2. Actually, all versions that use crypt+blowfish are affected. A suggestion was made to run a hash function such as sha256 on the input string and then proceed with bcrypt [2].

scrypt and pbkdf2 do not seem to expose this issue.


Test script:
$key1 = str_repeat("x", 72);
$key2 = $key1 . "x";
$hash = password_hash($key1, PASSWORD_DEFAULT);
if (password_verify($key2, $hash)) {
	echo "FAILED\n";
} else {
	echo "PASSED\n";

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-29 16:29 UTC]
-Assigned To: +Assigned To: ircmaxell
 [2013-03-29 16:40 UTC]
Any code-level "fix" would break compatibility with crypt(3). Which I'm not 
comfortable doing.

With that said, I agree that it should be documented. I'll add a warning against 

Additionally, considering this "bug" effects crypt(3) in its entirety, perhaps 
it should be raised there, so a standard solution could be found (or agreed upon 
that it's minor enough to not worry about). If we can get the crypt() community 
to agree on a fix, I'd be happy to participate on that discussion.
 [2017-01-16 14:41 UTC]
-Status: Assigned +Status: Closed -Type: Security +Type: Documentation Problem
 [2017-01-16 14:41 UTC]
It looks like this has been documented in the meantime, so closing here.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Apr 15 12:01:24 2021 UTC