php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #51282 crypt() result different between PHP 5.3.1 and PHP 5.3.2
Submitted: 2010-03-12 10:54 UTC Modified: 2010-03-31 01:48 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: jerome dot auge at anakeen dot com Assigned: joey (profile)
Status: Not a bug Package: *Encryption and hash functions
PHP Version: 5.3.2 OS: Mac, Linux
Private report: No CVE-ID: None
 [2010-03-12 10:54 UTC] jerome dot auge at anakeen dot com
Description:
------------
I use crypt() to store and validate passwords using the « Standard DES » hash, and after upgrading to 5.3.2, the hashed password of an account is not the same as the one generated with PHP 5.3.1 :

With PHP 5.3.1 :

  $ php -r 'print crypt("anakeen", "A^")."\n";'
  A^1ul2Jf7VS2M

After upgrading to PHP 5.3.2 :

  $ php -r 'print crypt("anakeen", "A^")."\n";'
  A^/ImZ5hqd2VU

I tested both on Mac (macports) and on Linux (rawhide), and the hash result was different on both platform.

On Mac OS X (10.5), the Perl (or C) crypt gives me the same results as PHP 5.3.1 :

  $ perl -e 'print crypt("anakeen", "A^")."\n";'
  A^1ul2Jf7VS2M

While on Linux, the Perl script gives me the same result as PHP 5.3.2.

It appears that there is a difference in the crypt() function, between these platforms, regarding the presence of non alpha-num chars in the salt :

Mac OS X with "A-" salt = different hashes :
 
  $ php -r 'print crypt("anakeen", "A-")."\n";'
  A-75An91LCLEM
  $ perl -e 'print crypt("anakeen", "A-")."\n"';
  A-1ul2Jf7VS2M

Mac OS X with "A9" salt = same hashes :

  $ perl -e 'print crypt("anakeen", "A9")."\n"';
  A9Pf3.gAayQMM
  $ php -r 'print crypt("anakeen", "A9")."\n";'
  A9Pf3.gAayQMM

Maybe I should not have used non alpha-num chars for my salt in the first place ?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-12 12:34 UTC] joey@php.net
-Status: Open +Status: Assigned -Type: Bug +Type: Documentation Problem -Assigned To: +Assigned To: joey
 [2010-03-30 00:53 UTC] paul dot fernandez at gmail dot com
I have a similar problem going from PHP 5.2.8 to 5.3.0.

<?php
        if(CRYPT_STD_DES == 1) { echo "Standard DES is available.\n\n"; }

        $username = 'aardvark';
        $password = 'password';

        $salt = substr($username, 0, 1);
        echo "\$salt = $salt\n";

        $pass = crypt($password, $salt);
        echo "Standard crypt encryption (1 char salt)  = '$pass'\n";

        $des_pass = crypt($password, 'a$');
        echo "DES encryption (2 char salt) = '$des_pass'\n";
?>


Output from PHP 5.3.0:

$ php test24.php
Standard DES is available.

$salt = a
Standard crypt encryption (1 char salt)  = 'a$Av8awQ0AsR6'
DES encryption (2 char salt) = 'a$Av8awQ0AsR6'


Output of the same code on PHP 5.2.8:

$ php test24.php
Standard DES is available.

$salt = a
Standard crypt encryption (1 char salt)  = 'a$LHSkrbhfU1.'
DES encryption (2 char salt) = 'a$LHSkrbhfU1.'
 [2010-03-30 01:53 UTC] joey@php.net
-Status: Assigned +Status: Bogus
 [2010-03-30 01:53 UTC] joey@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The salt has to come from the alphabet "./0-9A-Za-z", and using characters outside this range will result in undefined behaviour. As of 5.3.1, this is handled by not using the illegal characters as part of key in order to have consistent behaviour on all platforms.

cf:
http://www.gnu.org/s/libc/manual/html_node/crypt.html
http://www.manpages.info/freebsd/crypt.3.html
http://docs.sun.com/app/docs/doc/816-5175/crypt-unix-5?l=en&a=view
 [2010-03-30 23:35 UTC] paul dot fernandez at gmail dot com
You are correct.  When I switched to using a two character alpha-numeric salt, both PHP 5.2.8 and 5.3.0 returned the same encrypted string.  However, if I use a one character alpha-numeric salt, I get a different result on PHP 5.2.8 and 5.3.0:

<?php
        $password = 'password';

        $salt = 'a';
        $des_pass = crypt($password, $salt);
        echo "DES encryption (salt = $salt) = $des_pass\n";
?>

PHP 5.2.8:

$ php test27.php 
DES encryption (salt = a) = a$LHSkrbhfU1.

PHP 5.3.0:

$ php test27.php 
DES encryption (salt = a) = a$Av8awQ0AsR6


I wouldn't ordinarily break the rules, so-to-speak, by using a one character salt, but I'm trying to match an encryption created by a one character salt.  Is this also producing undefined behavior because of the shortness of the salt?

Thanks
 [2010-03-31 00:07 UTC] joey@php.net
Paul:
Yes, it's definitely undefined behaviour. However, I can't duplicate this - are 
you using 5.3.0 and 5.2.8 on different operating systems? Prior to 5.3.2, PHP 
would call the underlying OS's crypt() - so, on platforms that use the "UFC" 
crypt() (Linux, Sun, certain BSDs) you might get a different result than ones that 
use the FreeSec 1.0 crypt() (Mac OS X, OpenBSD).
 [2010-03-31 01:04 UTC] paul dot fernandez at gmail dot com
Yes, for the output I submitted, I was running this on two different systems, both Solaris 10.  However, for troubleshooting purposes, a coworker installed PHP 5.2.8 on the same system that is running 5.3.0 so that we could test if it was perhaps the OS or some library that was causing this issue, and we still see different encrypted outputs for a single character alpha-numeric salt.

Below is the output of running the same PHP script using two different versions of PHP on the same server:

$ /sw/php/bin/php test27.php 
DES encryption (salt = a) = a$Av8awQ0AsR6

$ /sw/php/bin/php --version
PHP 5.3.0 (cli) (built: Aug 12 2009 19:24:06) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

$ /sw/php528/bin/php test27.php 
DES encryption (salt = a) = a$LHSkrbhfU1.

$ /sw/php528/bin/php --version  
PHP 5.2.8 (cli) (built: Mar 25 2010 19:40:18) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

$ uname -a
SunOS *hostname* 5.10 Generic_138888-03 sun4u sparc SUNW,Sun-Fire-V490
 [2010-03-31 01:48 UTC] pajoye@php.net
That's exactly why we have to fix that in recent 5.3 releases. We also use a common implementation internally to be sure that every OS and no matter which version of PHP (from now on) will get the same results for the same input.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Fri Jun 22 17:01:44 2018 UTC