php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51996 crypt (md5) with same key and salt specified gives different output
Submitted: 2010-06-04 19:19 UTC Modified: 2010-06-05 16:08 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: phpbug dot z dot pbowers at spamgourmet dot com Assigned: pajoye (profile)
Status: Not a bug Package: hash related
PHP Version: 5.3.2 OS: windows 7
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: phpbug dot z dot pbowers at spamgourmet dot com
New email:
PHP Version: OS:

 

 [2010-06-04 19:19 UTC] phpbug dot z dot pbowers at spamgourmet dot com
Description:
------------
My understanding of the crypt() function is that it prepends the salt onto the resulting hash.  Thereafter feeding the resulting hash as the salt argument to the crypt() function with the same original key should result in the same hash.  We have used this extensively to encrypt/store and compare passwords for authentication purposes.

Thus the following code should result in "MATCH":

(see example A below)

In any version I've tested of PHP on a linux platform as well as 5.2.11 on a windows platform I get "MATCH" -- this is correct.  But on 5.3.0 or 5.3.1 or 5.3.2 on windows I get "NO MATCH".  

(see Example B below)

On any PHP version on a linux platform or on any pre-PHP 5.3.0 version on windows I get all identical hashes - this is good (same key, same salt, should result in the same hash).  But on any PHP 5.3.0 or later on windows I get all 4 being different (same first 12 characters).

I have verified that this bug occurs ON A WINDOWS PLATFORM (WAMPSERVER) in 5.3.0 and 5.3.1 and 5.3.2 but does not happen on 5.2.11.

I have verified that this bug does not occur on a linux platform running sample versions of 5.3.x.

I have verified that if I use a key of 4 or more characters the bug disappears.  Thus if you replace "abc" with "abcd" in the above code everything works fine across the board.  This bug only occurs with a key of 3 or fewer characters.

Why is this important?  I'm using code similar to this to determine whether passwords stored as encrypted hash match the password users just entered -- if they use a short password (3 or less characters -- not wise, but in a low-security environment there's been no need to limit that) then moving to 5.3.x means they can no longer log in.

Test script:
---------------
Example A:

$foo = crypt("abc");
$bar = crypt("abc", $foo);
if ($foo == $bar) echo "MATCH";
else echo "NO MATCH";

Example B:

$hash0 = crypt('abc');
$hash2 = crypt('abc', $hash0);
$hash3 = crypt('abc', $hash2);
$hash4 = crypt('abc', $hash3);
echo "local config: <br>\nhash0=$hash0, <br>\nhash2=$hash2<br>\nhash3=$hash3<br>\nhash4=$hash4<br>\n";


Expected result:
----------------
Example A:

Expect output of "MATCH"

Example B:

Expect 4 identical hashes to be printed, like this (obtained from 5.2.11):

local config:
hash0=$1$xH3.mL5.$GVkUEah6QIRaB7lZXfBz7.,
hash2=$1$xH3.mL5.$GVkUEah6QIRaB7lZXfBz7.
hash3=$1$xH3.mL5.$GVkUEah6QIRaB7lZXfBz7.
hash4=$1$xH3.mL5.$GVkUEah6QIRaB7lZXfBz7.

Actual result:
--------------
Example A (on a windows machine running 5.3.x):

NO MATCH

Example B (on a windows machine running 5.3.x):

local config:
hash0=$1$ta2.y55.$BYwQQt5ybMoX9I6Yqa5gX1,
hash2=$1$ta2.y55.$ngRiBNwmsuMxW.9B7OTB3/
hash3=$1$ta2.y55.$D4w8u73CH0ljNiwgqkX9p0
hash4=$1$ta2.y55.$ytnCYJ3ZKie4Fkei4SBmu.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-05 08:08 UTC] phpbug dot z dot pbowers at spamgourmet dot com
See http://bugs.php.net/bug.php?id=49954 - a friend pointed this out to me after I submitted this.

However, I note that that bug is marked as "closed" in 5.3.2-dev.  And that bug did not clearly specify that it was windows-only.  My fear is that the bug was closed after somebody tested 5.3.2-dev on linux or some other platform.
 [2010-06-05 15:49 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: pajoye
 [2010-06-05 15:55 UTC] phpbug dot z dot pbowers at spamgourmet dot com
Looking around at the sources I see that "windows platform" may not be specific enough.  I'm talking about the v6 build under wampserver.  If the bug referenced above was reliably reproduced on the same platform under 5.3.x and then shown to be fixed in 5.3.2-dev then this bug-report can be closed with that other one.  If not then I'm thinking both should remain open...

(If someone can point me to instructions where to download the PHP code and make a binary I'm willing to confirm one way or the other...  But I don't have access to any compilers other than what can be downloaded...)
 [2010-06-05 16:08 UTC] pajoye@php.net
-Status: Assigned +Status: Bogus
 [2010-06-05 16:08 UTC] pajoye@php.net
As said in the other bug report, this issue has been fixed. The code is not platform specific. Bogus (duplicated). Fix will be present in the next release.

Output Example #A:
MATCH

Output current SVN for example #B:
local config: <br>
hash0=$1$Eb..7r1.$wV.jr8E4XOOGoy3WWFHAg., <br>
hash2=$1$Eb..7r1.$wV.jr8E4XOOGoy3WWFHAg.<br>
hash3=$1$Eb..7r1.$wV.jr8E4XOOGoy3WWFHAg.<br>
hash4=$1$Eb..7r1.$wV.jr8E4XOOGoy3WWFHAg.<br>
 [2010-07-02 09:02 UTC] ashish3253 at yahoo dot com
I faced the same problem in vTiger CRM. I am using Wamp Server 2 with PHP 5.3.0. If the password is 5 or less characters, I am not able to login. For 6 or more character password, it works fine. vtiger uses crypt function to encrypt the password. Thanks to this thread, I found out what was wrong with the login. On another system, I have Wamp server 1 installed, and no such issue is happening there
 [2011-09-10 21:34 UTC] c dot clix at tiscali dot it
On my PHP 5.3.6 on WIN 32bit (windows server 2003) installation, this BUG appears to be still unsolved.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 12 18:01:26 2024 UTC