php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65093 password_hash ignores salts with spaces
Submitted: 2013-06-21 22:37 UTC Modified: 2013-06-24 00:15 UTC
From: michael at squiloople dot com Assigned: ircmaxell (profile)
Status: Not a bug Package: hash related
PHP Version: 5.5.0 OS: Windows Vista SP2
Private report: No CVE-ID: None
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: michael at squiloople dot com
New email:
PHP Version: OS:

 

 [2013-06-21 22:37 UTC] michael at squiloople dot com
Description:
------------
When manually setting a salt which contains spaces the function ignores it and 
automatically generates its own.

Test script:
---------------
  echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 'thisisatestthisisatest'));

  echo '<br>';

  echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 'thisisatestthisis test'));

Expected result:
----------------
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO

(with the part after the salt being whatever it would be)

Actual result:
--------------
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-22 05:48 UTC] remi@php.net
I think it's only a documentation problem which should explains which are the allowed characters in the salt (from code: a-z A-Z 0-9 . /)

(notice: It is strongly recommended that you do not generate your own salt for this function)
 [2013-06-22 12:36 UTC] michael at squiloople dot com
Would it be worth then having an error or a boolean/null return value rather than 
have it "fail" silently? If at any point the allowed characters for the salt were 
to extend then past hashes (where a salt was generated by the developer with 
previously invalid characters) would be broken.

If you give the developer the option to provide a value then surely it should be 
either accepted or denied rather than just ignored.
 [2013-06-24 00:07 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: ircmaxell
 [2013-06-24 00:15 UTC] ircmaxell@php.net
-Status: Assigned +Status: Not a bug
 [2013-06-24 00:15 UTC] ircmaxell@php.net
This is not a bug. This is as designed.

The reason is that crypt requires a salt that's base64 encoded. A space 
character is not a valid character in the salt. Therefore, password_hash will 
attempt to use the salt directly (if it's valid in the base64 character set). 
But any character outside a-zA-Z0-9./ and it'll base64 encode the salt first. 
You can test this yourself:

echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisis test'));
echo "\n";
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' => 
'thisisatestthisis test'));

Produces the same result twice in a row:

$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO

Which indicates that it's actually encoding the salt you pass in, rather than 
generating a random one.

So it's still using your salt, and it's most definitely not failing.

Closing as Not A Bug. Thanks for the report!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 03:01:28 2024 UTC