php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #55717 Crypt returns "*0" instead of hashed string.
Submitted: 2011-09-17 18:15 UTC Modified: 2011-09-18 21:27 UTC
Votes:15
Avg. Score:4.4 ± 0.7
Reproduced:11 of 11 (100.0%)
Same Version:3 (27.3%)
Same OS:1 (9.1%)
From: gelliott000 at yahoo dot ca Assigned:
Status: Open Package: *Encryption and hash functions
PHP Version: 5.3.8 OS: FreeBSD 7.2
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-09-17 18:15 UTC] gelliott000 at yahoo dot ca
Description:
------------
PHP 5.3.8 with Suhosin-Patch (cli) (built: Sep 12 2011 10:57:59)

Using the crypt() function with string "veronica" and salt "_Q" returns an unexpected string: "*0".

Was expecting a proper hashed string beginning with the salt string to be returned.


Test script:
---------------
<?php
echo crypt("veronica","_Q");
?>


Expected result:
----------------
A hashed string beginning with the salt string to be returned.

Actual result:
--------------
The string "*0" is returned.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-17 18:30 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2011-09-17 18:30 UTC] pajoye@php.net
Please try using a plain PHP fetched either from our svn or from a release 
download.
 [2011-09-17 19:34 UTC] gelliott000 at yahoo dot ca
-Status: Feedback +Status: Open
 [2011-09-17 19:34 UTC] gelliott000 at yahoo dot ca
I have been able to reproduce the bug under Ubuntu Linux (2.6.32) and a clean 5.3.8 release download:  PHP 5.3.8 (cli) (built: Sep 17 2011 14:59:12)
 [2011-09-17 19:46 UTC] pajoye@php.net
-Status: Open +Status: Bogus
 [2011-09-17 19:46 UTC] pajoye@php.net
ah, sorry, I misread the *0 part. Please see the documentation (salt length, 
return value on failure).
 [2011-09-17 23:53 UTC] gelliott000 at yahoo dot ca
I'm sorry to be persistent, but I don't think that this is a problem with the salt length.

To demonstrate, I have run crypt on several platforms with several versions of PHP.  I ran crypt with the same string, but a different salt that varied by just one character:

1st case:  crypt("veronica", "aQ");
2nd case:  crypt("veronica", "_Q");

The first case produces the same hashed string in all versions and platforms.
The second cases produces a proper hashed string with the 5.1 and 5.2 variants, but not so with most of the 5.3 variants.

Results for 1st case [crypt("veronica", "aQ")]:
PHP 5.1.6 (cli) / RHEL Linux 2.6.18:  aQW/7xmAl9Wk.
PHP 5.2.17 (cli) / RHEL Linux 2.6.18:  aQW/7xmAl9Wk.
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) / Linux :  aQW/7xmAl9Wk.
PHP 5.3.0 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.4 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.6 (cli) / RHEL Linux 2.6.18: aQW/7xmAl9Wk.
PHP 5.3.8 (cli) / Ubuntu Linux (2.6.32):  aQW/7xmAl9Wk.
PHP 5.3.8 with Suhosin-Patch (cli) / FreeBSD 7.2 :  aQW/7xmAl9Wk.


Results for the 2nd case [crypt("veronica", "_Q")]:

PHP 5.1.6 (cli) / RHEL Linux 2.6.18:  _Q9SLgD4qEEgM
PHP 5.2.17 (cli) / RHEL Linux 2.6.18:  _Q9SLgD4qEEgM
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch (cli) / Linux :  _Q9SLgD4qEEgM
PHP 5.3.0 (cli) / RHEL Linux 2.6.18: _Q$$$$$$$qK1ZM2vrJkU
PHP 5.3.4 (cli) / RHEL Linux 2.6.18: *0
PHP 5.3.6 (cli) / RHEL Linux 2.6.18: *0
PHP 5.3.7 with Suhosin-Patch (cli) / FreeBSD 7.2 :   *0
PHP 5.3.8 (cli) / Ubuntu Linux (2.6.32):  *0
PHP 5.3.8 with Suhosin-Patch (cli) / FreeBSD 7.2 :   *0
 [2011-09-18 21:27 UTC] tyrael@php.net
-Status: Bogus +Status: Open
 [2011-09-18 21:27 UTC] tyrael@php.net
it is not about the length, and not about having underscore in the salt, as then 
both '_a' and 'a_' should produce *0, but it isn't:
crypt("veronica", "a_") returns  'a_CzfMnN285eI'
I also tried calling crypt with longer salt:
crypt("veronica", "aaaaaaaaaaaaaaaa_");
produces "aaN/k77JE/bN6" on both 5.2.17 and 5.3.8
but crypt("veronica", "_aaaaaaaaaaaaaaaa"); differs:
"_aaaaaaaadgbQ2NJa866" for 5.3.8
"_aeK.1tgvo.I." for 5.3.8

so it seems that _ only cause problems, if it is in the first position of the 
salt.

ps: I also tried replacing the starting undescore with other "special" 
characters(^,!,#), they produced the same result on both 5.2.18 and 5.3.8, so it 
seems that it happens only with underscore.

could someone have another look?
 [2011-09-19 17:00 UTC] nikic@php.net
@tyrael: If the salt starts with an underscore it's an Extended DES hash, not a standard DES hash.

The actual problem is that this should give (*0) everywhere as far as I can see: PHP fills the salt up to max salt length with '$' and this isn't a valid Extented DES count or salt.

The relevant code is here: http://lxr.php.net/xref/PHP_5_3/ext/standard/crypt_freesec.c#638
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Jun 24 15:01:26 2019 UTC