php.net |  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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: lekensteyn at gmail dot com
New email:
PHP Version: OS:

 

 [2013-03-28 11:53 UTC] lekensteyn at gmail dot com
Description:
------------
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.

 [0]: https://github.com/ircmaxell/password_compat
 [1]: http://www.openwall.com/crypt/
 [2]: http://security.stackexchange.com/q/6623/2630

Test script:
---------------
<?php
$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:
----------------
PASSED

Actual result:
--------------
FAILED

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-29 16:29 UTC] rasmus@php.net
-Assigned To: +Assigned To: ircmaxell
 [2013-03-29 16:40 UTC] ircmaxell@php.net
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 
that.

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] nikic@php.net
-Status: Assigned +Status: Closed -Type: Security +Type: Documentation Problem
 [2017-01-16 14:41 UTC] nikic@php.net
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