php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76842 password_verify returns true comparing null and \0
Submitted: 2018-09-05 00:19 UTC Modified: 2018-12-06 22:32 UTC
Votes:5
Avg. Score:3.0 ± 1.3
Reproduced:0 of 2 (0.0%)
From: leon at valkenb dot org Assigned:
Status: Verified Package: *Encryption and hash functions
PHP Version: 7.1.21 OS: Ubuntu
Private report: No CVE-ID: None
View 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 !
Your email address:
MUST BE VALID
Solve the problem:
8 + 32 = ?
Subscribe to this entry?

 
 [2018-09-05 00:19 UTC] leon at valkenb dot org 
Description:
------------
password_verify() returns true when hashed null is passed and string of nulls used to verify against, password_verify() thinks all is OK.

Given this is not that likely to be an issue, i have seen production databases that have gone and encrypted raw password with password_hash() and many values were null, an i was able to log into the sites knowing the email address and passing a string of nulls as the password.

Test script:
---------------
$check = "\0\0\0\0\0\0";

$hash = password_hash(null, PASSWORD_DEFAULT);

if (empty($check)){
	exit('No Password');
}

if (strlen($check) < 5){
	exit('Wrong Length');
}

var_dump(password_verify($check, $hash));

Expected result:
----------------
bool(false)

Actual result:
--------------
bool(true)

Patches

password-as-path (last revision 2018-09-06 11:37 UTC by cmb@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-09-05 10:35 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2018-09-05 10:35 UTC] cmb@php.net 
This might be related to bug #74473.
 [2018-09-05 20:34 UTC] leon at valkenb dot org 
Is there any way i can see ug #74473 as its marked private?
 [2018-09-06 11:37 UTC] cmb@php.net
-Summary: Possible authentication attuck vector +Summary: Possible authentication attack vector
 [2018-09-06 11:37 UTC] cmb@php.net 
> Is there any way i can see ug #74473 as its marked private?

No, sorry.  Security reports are private to the reporter, and to
those with sec karma.

Anyhow, on a closer look I'm not sure this is really a bug at all.
password_hash()ing NULL is equivalent to password_hash()ing an
empty string, and this should be checked and prohibited in the
first place in userland (“password too short”).  I consider it
unlikely that a user would circumvent this check by passing a
string of NULs.

Nonetheless, the password API should probably check for NUL bytes
in given passwords to prohibit such misuse.
 [2018-09-06 11:37 UTC] cmb@php.net 
The following patch has been added/updated:

Patch Name: password-as-path
Revision:   1536233879
URL:        https://bugs.php.net/patch-display.php?bug=76842&patch=password-as-path&revision=1536233879
 [2018-12-02 05:01 UTC] stas@php.net 
Doesn't seem to be likely scenario to have null as valid password.
 [2018-12-02 05:01 UTC] stas@php.net
-Summary: Possible authentication attack vector +Summary: password_verify returns true comparing null and \0 -Type: Security +Type: Bug
 [2018-12-06 22:32 UTC] leon at valkenb dot org 
....
Given this is not that likely to be an issue, i have seen production databases that have gone and encrypted raw password with password_hash() and many values were null, an i was able to log into the sites knowing the email address and passing a string of nulls as the password.
 [2021-10-09 13:04 UTC] divinity76 at gmail dot com 
this is a strict_types-related issue, enable strict_types=1 to get a proper error message and see what's going on: the null is converted to string before password_hash gets to see the input argument. 


albeit, IMO, both password_hash and password_verify should throw an InvalidArgumentException/ValueError/something when receiving a password-containing-null-bytes, as those retards use C-style strings and incorrectly believes that the passwords "foo\x00bar" and "foo\x00pizza" is the same password... but that should get its own issue
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Oct 26 05:00:01 2025 UTC