[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