[pmwiki-users] "PHP Deprecated: crypt()..."

Petko Yotov 5ko at 5ko.fr
Fri Jul 6 03:23:47 PDT 2018


On 05/07/2018 17:59, pce at accesswave.ca wrote:
> 1. Yes, I can log in.
> 2. I don't know the users' passwords, but I doubt that very short ones 
> exist.
> 3. It's quite likely that some of them were created by very old PHP
> versions, but none was migrated from a different operating system.
> 
> I notice that some of the encrypted passwords are much shorter than 
> others, e.g.
> 
> $1$4TkD8gnQ$rojTv9bGI/lel/e38yvra/
> $6$CIYQpx50ggMe$EHe4EtLNxo6L40SUQ2ge8ohZ83NXvljErVjGDuwqU2vV.FFdzWuGIEojsnsoVriTWj8GpuCSCNrQKqgOl0gza/

This is normal, previous PHP versions used different default hashing 
functions, these produce hashes of different lengths. Usually longer 
hashes are more recent and considered more secure, but normally older 
hashes can be tested and used without problems.

> Am I going to have to write to all of my users to ask them to test
> whether they can log in or not? Does the encrypted password length
> offer any clue as to whom I should be writing?

Probably no need to write to all: if someone cannot log in they will 
write to you.

In the past, specific PHP versions on Windows created invalid hashes for 
passwords of 3 characters or less, which couldn't be used by other PHP 
versions on other systems. If you can log in this is unlikely to be your 
case.

The message you describe (salt is invalid) happens most often when 
PmWiki checks a password against something that is not a valid password 
hash.

In the past PmWiki shipped its protected page files (in wikilib.d) with 
a password attribute set as "*" which indeed was not a valid hash, and 
even documented this for $DefaultPasswords settings. This was OK at the 
time, crypt() simply returned false, as in "the password doesn't match 
the hash", but now it raises a warning that indeed it is not a real 
hash.

For a few years we have shipped pages and have updated the documentation 
to say lock a page with "@lock" not with "*" but some old installations 
may still have a few files in wiki.d and/or in wikilib.d with the old 
password attribute, and migrating or upgrading your PHP version may 
cause the warning to appear out of the blue.

PmWiki 2.2.108 only fixes this specific pmcrypt() case when presented 
with "*" or "@" instead of a valid hash. If this fixes your warning, you 
probably had old protected files in your wiki.d or wikilib.d 
directories. Otherwise we'll need to look more.

Petko

> 
> On 2018-07-05 12:40 PM, Petko Yotov wrote:
>> I've released 2.2.108 which should handle correctly old PmWiki 
>> password attributes * or @ which are not valid crypto salts and cause 
>> the warning. Please try it and report if this solves your problem or 
>> not.
>> 
>> Can you login at all? If not, are these passwords very short (< 4 
>> characters) or created by very old PHP versions, or was the wiki 
>> migrated from a different operating system than your current one (eg. 
>> Windows->Linux)? If so, you may have to re-type or re-generate your 
>> passwords on the current server.
>> 
>> Petko
>> 
>> On 05/07/2018 15:24, pce at accesswave.ca wrote:
>>> I'm getting the following error in my Apache error log:
>>> 
>>> mod_fcgid: stderr: PHP Deprecated:  crypt(): Supplied salt is not
>>> valid for DES. Possible bug in provided salt format. in
>>> /home/www/vdgsa.org/wiki/pmwiki.php on line 519
>>> 
>>> There is a reference to this on the PMWiki website's 
>>> "Troubleshooting"
>>> page <https://www.pmwiki.org/wiki/PmWiki/Troubleshooting>,
>>> recommending that all occurrences of crypt() be replaced with
>>> pmcrypt(). Unfortunately, the above error message refers to a line in
>>> pmcrypt itself, so that's not going to work, surely.
>>> 
>>> I'm running version 2.2.107 of pmwiki, and PHP 7.0.27.
>>> 
>>> Any suggestions?



More information about the pmwiki-users mailing list