Bug #51996 [Com]: crypt (md5) with same key and salt specified gives different output
Edit report at https://bugs.php.net/bug.php?id=51996&edit=1
ID: 51996
Comment by: c dot clix at tiscali dot it
Reported by: phpbug dot z dot pbowers at spamgourmet dot com
Summary: crypt (md5) with same key and salt specified gives
different output
Status: Bogus
Type: Bug
Package: hash related
Operating System: windows 7
PHP Version: 5.3.2
Assigned To: pajoye
Block user comment: N
Private report: N
New Comment:
On my PHP 5.3.6 on WIN 32bit (windows server 2003) installation, this BUG appears to be still
unsolved.
Previous Comments:
------------------------------------------------------------------------
[2010-07-02 09:02:33] 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
------------------------------------------------------------------------
[2010-06-05 16:08:56] 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-06-05 15:55:47] 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 08:08:34] 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-04 19:19:11] 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.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=51996&edit=1
Thread (7 messages)