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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: leon at valkenb dot org
New email:
PHP Version: OS:

 

 [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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 15:01:30 2024 UTC