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] paj...@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
