Note that there are some explanatory texts on larger screens.

plurals
  1. POPHP crypt() returning wrong answer
    primarykey
    data
    text
    <p>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.</p> <p>In my database, i've got the crypted version of the users password - so let's say Og12345678.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>It's consistent however, i.e. once the system has gone wrong crypt returns the wrong answer but it's always returning the <em>same</em> 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.</p> <p>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.</p> <p>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.</p> <p>Any input appreciated.</p> <p>Matt Peddlesden</p> <p><em>--- Update: 11 Mar 2011</em></p> <p>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.</p> <p>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 <em>changing the algorithm used to calculate the crypt() result</em>... 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. </p> <p>Anyone got any clues on what might cause this to happen?</p> <p>Whatever it was seemed to happen twice in one day yesterday, most odd.</p> <p>Thanks for the answers thus far.</p> <p><em>--- Update: 16 Mar 2011</em></p> <p>Just wanted to provide another update.</p> <p>This is still happening, still no further understanding of why.</p> <p>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.</p> <p>Of course if it <em>still</em> happens, that will be interesting to know too! :)</p> <p>Thanks all.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI think it's unlikely that this is your problem, but I see that the advice in the PHP documentation -- http://php.net/manual/en/function.crypt.php -- is that you should pass the whole (salted) crypted password in as the salt. `if (crypt($enteredPassword,$cryptedPasswordFromDB) == $cryptedPasswordFromDB) { ... }`. The point seems to be that then crypt() can determine what hashing algorithm is in use from $cryptedPasswordFromDB. Again, I doubt that this is the cause of your problem, but you might give it a go...
      singulars
    2. COIs it possible than a script change some php configuration resulting in a different hash function used by crypt ? Like said by @Gareth passing the complete password from the db can solve this problem.
      singulars
    3. COI 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 working 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.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload