The PHP crypt() function

[rixtertrader]

I have a PHP file that generates a htpasswd file based on a different password each day.

 

The part of the code that does this is shown below:

 

 

 

<?php

$clearTextPassword = $passstrings[$TodayDay];

 

$password = crypt($clearTextPassword, base64_encode($clearTextPassword));

 

$filepath = '/home/passwd';

 

// if the file exits, change the permissions

if (file_exists($filepath)) {

chmod($filepath, 0777);

}

 

// open password file to write

$fp = fopen($filepath, "w");

 

// write today's password phrase

fputs($fp, "mfsaccess01:$password\r\n");

 

// change permissions

chmod($filepath, 0644);

 

// close passwd file

fclose($fp);

 

echo '<h2 align="center">The password for today is the FIRST THREE WORDS found on page '.$pagenum[$TodayDay].'<br>

in the MFS book (first paragraph, not title). Please do not add punctuation. Include spaces and exact case.</h2>';

 

?>

[/code

 

The actual passwords are not shown in this code. It is a list of passwords in an array that is chosen based on the day and placed into the $clearTextPassword variable.

 

This code worked without any problems when I had my files on the Pair.com servers. Recently I moved this code to my GoDaddy server.

 

The code DOES generate a password and DOES create a new passwd file, but it appears the .htaccess file does not accept the password it has generated.

 

So I went to a site online and manually created a password in order to test my .htaccess passwd combo. That worked fine. So it is my generated passwd file that seems to be the fault.

 

My question is, does this PHP crypt function work differently on different servers?

 

Is there a setting, or do I need to make some kind of changes in order for this to work on my GoDaddy server?

 

I'm puzzled.

 

Thanks.

[requinix]

Not really. How did the correct crypt()ed password compare with the one your script generated?

 

Also,

crypt($clearTextPassword, base64_encode($clearTextPassword))

1. Insecure. Under normal circumstances the first two characters will be used from the base 64-encoded password as the salt, which is prepended to the output. That exposes a little more than the first character from the password. The salt should be random.

2. Buggy. Base 64 encoding results in a string consisting of characters from the alphabet a-z A-Z 0-9 plus slash equals. This guarantees that the only hash type possibly used is CRYPT_STD_DES but that type only accepts salts consisting of a-z A-Z 0-9 period slash. If the encoding produces a plus or equals in the first two characters then the salt is invalid and crypt() should (but apparently doesn't?) fail.

[rixtertrader]

How did the correct crypt()ed password compare with the one your script generated?

 

They did not compare. They were different.

 

I located a site that said to look at a series of constants to decide on the 'salt'.

 

Here is what my server returned.

 

CRYPT_SALT_LENGTH = 123

CRYPT_STD_DES = 1

CRYPT_EXT_DES = 1

CRYPT_MD5 = 1

CRYPT_BLOWFISH = 1

 

Does any of this help in deciding how to generate my password correctly?

[requinix]

What I didn't mention was that I assume you used DES on whatever site you tried getting the real password on. Because your code will use DES.

 

What password did you try, what did your script output, and what did the site say?