PHP crypt() returning wrong answer

I think i'm losing my marbles here... I've got a problem on my web site where randomly it stops accepting logins. I've now been able to trace it to crypt() behaving very strangely.

In my database, i've got the crypted version of the users password - so let's say Og12345678.

When the user logs in, they enter their password, I read the salt out of the db and then crypt what they entered and compare - usually this works very well.

So i'm doing crypt($enteredPassword, $saltFromDb) - in this case, the salt would be Og of course. Normally for a given users password crypt works fine.

When things go wrong (and when they do it's a permanent change until I restart Apache) I found that crypt starts returning a DIFFERENT answer for the same input with the same salt.

It's consistent however, i.e. once the system has gone wrong crypt returns the wrong answer but it's always returning the same wrong answer. Repeated refreshes of the page show the same output. The same salt is also in evidence in the newly incorrect crypt result also, so it's not that the salt has gone missing somewhere.

If I then restart Apache and re-run the script without any changes at all, the results from crypt are then back to how they should be.

I appreciate it's not the latest PHP (5.2.8) but would value any views on this including whether it's a known bug fixed in a later version (upgrading PHP is not a happy task with lots of sites some of which still use unfortunate quirks that all need to be re-tested with each upgrade) - if it is a known fixed bug then obviously i'll get it all upgraded ASAP, beyond that it'll probably be easier to outsource the crypt externally since I only use it in one common place for my site.

Any input appreciated.

Matt Peddlesden

--- Update: 11 Mar 2011

Correction to comment previously given about operating system... - Operating system is Windows Server 2008 SP1 64 bit. Apologies I should have double checked rather than assuming I could remember! Machine is a Dell 2950 8gb Ram, Xeon processors.

I am starting to think along the lines Krtek is suggesting - when the system has gone wonky, if I generate new crypt() (i.e a very simple example where i set a variable to a string, crypt it and then compare with the crypt) - all works great. When I restart the server, again it's all back to the previous calculations again. So I am definitely leaning towards something that is changing the algorithm used to calculate the crypt() result... any thoughts on what might cause this to happen? I printed out the values of the CRYPT_STD_DES etc and they don't change between restarts.

Anyone got any clues on what might cause this to happen?

Whatever it was seemed to happen twice in one day yesterday, most odd.

Thanks for the ans开发者_StackOverflow社区wers thus far.

--- Update: 16 Mar 2011

Just wanted to provide another update.

This is still happening, still no further understanding of why.

In case anyone comes across this in the future, I think my solution going forwards is going to be to do some nasty hack to push all the crypt() executions out to an external C# application and stop having to rely on PHP to do them. Something is going wrong somewhere and at this point the only solution I can see is to remove it from the equation entirely.

Of course if it still happens, that will be interesting to know too! :)

Thanks all.

Why are you reading the salt? And how are you getting the salt? Different algorithms use different methods for including the salt in the output.

Just use the whole output of the crypt function as the second argument:

  $crypted='Og12345678';
  if (crypt($_POST['password'], $crypted)==$crypted) {
      ....

And single pass DES? Really?

Last time I looked, the PHP crypt implementation would call the crypt() function provided by the system - so if it has broekn then its more likely to be your OS than PHP - but you didn't say what your OS is.

It might be the Suhosin PHP security patch affecting your crypt() function. It alters a lot of the encryption/random methods and may be the the cause of your problem.

Check a phpinfo() and see if 'suhosin' is anywhere on the page. If it's there, look into disabling some of it's features in the php config.

i had the same problem with crypt... I had that login-check working on 2 servers, but when i transfer it to the newest one it eventually stop working. I walk around it with md5 encryption as follows: In register.php

 $encrypted = md5($_POST["pass"]);
 ...

And then in login.php

$password = md5($_POST["password"]);
 if ($password == $row["hash"])
        {
            // remember that user's now logged in by storing user's details in session
            $_SESSION["id"] = $row["id"];
            $_SESSION['username'] = $_POST['username'];
            $_SESSION['logged'] = 'Yes';
            // redirect to homepage
            redirect("index.php");
        }

I hope that helps :)

I faced the same problem. Since moving my vTigerCRM installation to local machine, user login with previously stored passwords started failing. It seems like crypt() is returning different hashes on different environments with the same arguments:

On local environment:

SYSTEM: Windows NT 6.1 build 7601 (Business Edition Service Pack 1) i586
PHP: 5.3.5

crypt('hello world','$1$ad0000000'):

     $1$ad00000008tTFeywywdEQrAl9QzV.M1

On production environment:

SYSTEM: Linux 2.6.18-338.9.1.el5.lve0.8.32 #1 x86_64
PHP: 5.3.5

crypt('hello world','$1$ad0000000'):

    $1$ad000000$8tTFeywywdEQrAl9QzV.M1