|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #71918 hash_pbkdf2() strips trailing \0 in $password
Submitted: 2016-03-29 12:25 UTC Modified: 2016-04-01 02:26 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: gelenkig at runbox dot com Assigned:
Status: Open Package: hash related
PHP Version: 5.5.33 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2016-03-29 12:25 UTC] gelenkig at runbox dot com
hash_pbkdf2() must return different hashes for different $password's but it returns the same hash no matter how many trailing NUL bytes $password has.

Test script:
// all 3 variables contain the same hash.
$h1 = hash_pbkdf2('sha256', "password", 'salt', 1000);
$h2 = hash_pbkdf2('sha256', "password\0", 'salt', 1000);
$h3 = hash_pbkdf2('sha256', "password\0\0", 'salt', 1000);
// prints TRUE, TRUE but it must be 3 separate hashes: FALSE, FALSE.
var_dump($h1===$h2, $h1===$h3);

Expected result:
hash of password !== hash of password\0 !== hash of password\0\0 !== ...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-03-29 12:27 UTC] gelenkig at runbox dot com
Same problem with openssl_pbkdf2(). If it's expected behaviour it must be documented.

// all 3 variables contain the same hash.
$h1 = openssl_pbkdf2("password", 'salt', 40, 1000, 'sha256');
$h2 = openssl_pbkdf2("password\0", 'salt', 40, 1000, 'sha256');
$h3 = openssl_pbkdf2("password\0\0", 'salt', 40, 1000, 'sha256');
// TRUE, TRUE - wrong.
var_dump($h1===$h2, $h1===$h3);
 [2016-03-29 13:03 UTC]
Passwords with trailing null bytes up to the block length of the used hash function giving the same result is expected when using PKBDF2 with an HMAC as the PRF. Notably, quoting from RFC 2104, the first step of the HMAC construction is:

    (1) append zeros to the end of K to create a B byte string
        (e.g., if K is of length 20 bytes and B=64, then K will be
         appended with 44 zero bytes 0x00)
 [2016-03-29 13:04 UTC]
-Type: Bug +Type: Documentation Problem
 [2016-04-01 02:26 UTC]
IMO, \0 in supplied password text should raise error because user should never supply text contains \0.

PHP developers must detect invalid strings by input validation, so this is minor issue though.
 [2016-04-01 11:26 UTC] gelenkig at runbox dot com
I agree with that it must result in an error or at least a E_WARNING but I don't agree that "developers should already validate the input" - checking length is common, checking for recommended symbols is also considered but who will check for \0 presence? I wouldn't even think of this.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 20:01:34 2024 UTC