[pmwiki-devel] crypt problem on WAMP
Peter Bowers
and wondering if anybody can shed light...
Here's what I've got in my config.php right now (minus comments):
$hash0 = crypt('abc'); // as (:encrypt abc:) would output
$hash2 = crypt('abc', $hash0); // as encrypted as part of Site.AuthForm login
$hash3 = crypt('abc', $hash2); // ditto
$hash4 = crypt('abc', $hash3); // ditto
echo "local config: <br>\nhash0=$hash0,
<br>\nhash2=$hash2<br>\nhash3=$hash3<br>\nhash4=$hash4<br>\n";
and here's what it outputs:
local config:
hash0=$1$Nm2.Sh4.$I/N20HxaAHHWIk0Yx75cc0,
hash2=$1$Nm2.Sh4.$TY4dd776IXYNbcfXDoONx.
hash3=$1$Nm2.Sh4.$Jb4Co57IMoIAc.Yut.l/J.
hash4=$1$Nm2.Sh4.$4hdZM5bSNnZrP8bDOXq0q1
Note that the salt is identical, but the resulting crypted code is
different between hash0 and the rest. Obviously this results in the
password being stored in SiteAdmin.AuthUser (which is generated like
hash0 is generated) does not match the passwords crypted from
Site.AuthForm (which are generated as hash2 and etc. are generated).
(At different points during my testing hash2-4 have been identical,
but always different from hash0.)
Eemeli tried this on linux servers and it results in identical hashes
between hash0 and the rest (as expected). Any idea what could cause
the WAMP server to do otherwise?
-Peter
_______________________________________________
pmwiki-devel mailing list
pmwiki...@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
Dominique Faure
Hi,
As a workaround, have you tried to use the _crypt(...) version defined
in scripts/authuser.php ?
--
Dominique
Eemeli Aro
> As a workaround, have you tried to use the _crypt(...) version defined
> in scripts/authuser.php ?
Gives the same results. With hashes that start '$1$', internally
_crypt() just calls crypt() with the same parameters it's passed.
eemeli
Peter Bowers
> On 4 June 2010 16:29, Dominique Faure <dominiq...@gmail.com> wrote:
>> As a workaround, have you tried to use the _crypt(...) version defined
>> in scripts/authuser.php ?
>
> Gives the same results. With hashes that start '$1$', internally
> _crypt() just calls crypt() with the same parameters it's passed.
Confirmed. I actually started with calls to _crypt() and then tried
to simplify my config.php by not including authuser.php or any other
scripts and still got the same result with crypt() directly.
-Peter
Dominique Faure
> On Fri, Jun 4, 2010 at 3:33 PM, Eemeli Aro <eem...@gmail.com> wrote:
>> On 4 June 2010 16:29, Dominique Faure <dominiq...@gmail.com> wrote:
>>> As a workaround, have you tried to use the _crypt(...) version defined
>>> in scripts/authuser.php ?
>>
>> Gives the same results. With hashes that start '$1$', internally
>> _crypt() just calls crypt() with the same parameters it's passed.
>
> Confirmed. I actually started with calls to _crypt() and then tried
> to simplify my config.php by not including authuser.php or any other
> scripts and still got the same result with crypt() directly.
I ran the following code under different PHP version on the same Vista
host and there seems to be severe php bugs on Windows :(
Feel free to open a bug report using these results.
<?php
echo "local config: " . PHP_VERSION . "\n";
echo "CRYPT_SALT_LENGTH: " . CRYPT_SALT_LENGTH . "\n";
$hash0 = crypt('abc');
$salt0 = substr($hash0, 0, CRYPT_SALT_LENGTH);
$salt1 = preg_replace("/[^$]+$/", "", $hash0);
echo "
hash0=$hash0 (initial hash)
salt0=$salt0 (salt as specified)
salt1=$salt1 (salt extracted)
";
$hash1 = crypt('abc', $hash0);
$hash2 = crypt('abc', $salt0);
$hash3 = crypt('abc', $salt1);
echo "
hash1=$hash1 (full hash)
hash2=$hash2 (salt as specified)
hash3=$hash3 (salt extracted)
";
=====
D:\WebOnKey\phpbatch>phpbatch.cmd crypt_test.php
local config: 5.2.11
CRYPT_SALT_LENGTH: 12
hash0=$1$QB3.ZN1.$5tkZ7UCuwUjYqq2Z3Ta6B0 (initial hash)
salt0=$1$QB3.ZN1.$ (salt as specified)
salt1=$1$QB3.ZN1.$ (salt extracted)
hash1=$1$QB3.ZN1.$5tkZ7UCuwUjYqq2Z3Ta6B0 (full hash)
hash2=$1$QB3.ZN1.$5tkZ7UCuwUjYqq2Z3Ta6B0 (salt as specified)
hash3=$1$QB3.ZN1.$5tkZ7UCuwUjYqq2Z3Ta6B0 (salt extracted)
=====
D:\WebOnKey\phpbatch>phpbatch.cmd crypt_test.php
local config: 5.3.0
CRYPT_SALT_LENGTH: 60
hash0=$1$5l3.ol/.$AXA9xtue/DFFPGTW4haT90 (initial hash)
salt0=$1$5l3.ol/.$AXA9xtue/DFFPGTW4haT90 (salt as specified)
salt1=$1$5l3.ol/.$ (salt extracted)
hash1=$1$5l3.ol/.$xaIezL3QmvNqsDx2YF/0O/ (full hash)
hash2=$1$5l3.ol/.$i3zfzb8ps1gYRpuU.yUnI1 (salt as specified)
hash3=$1$5l3.ol/.$AG4.yHS4uBrbKbrv9xK.i1 (salt extracted)
=====
D:\WebOnKey\phpbatch>phpbatch.cmd crypt_test.php
local config: 5.3.2
CRYPT_SALT_LENGTH: 123
hash0=$1$8r/.vg4.$mN8JfO5qXyCVZaGKgQpjr. (initial hash)
salt0=$1$8r/.vg4.$mN8JfO5qXyCVZaGKgQpjr. (salt as specified)
salt1=$1$8r/.vg4.$ (salt extracted)
hash1=$1$8r/.vg4.$E.2nI.Am1ykwMEY6QrB4j/ (full hash)
hash2=$1$8r/.vg4.$kpuyMfqpfu5GEeDq39lP4. (salt as specified)
hash3=$1$8r/.vg4.$qnc1GGeOQWNdfqLi2C1qD1 (salt extracted)
--
Dominique
Petko Yotov
> I am having difficulty with some authorization code on a WAMP server
> and wondering if anybody can shed light...
>
> Here's what I've got in my config.php right now (minus comments):
>
> $hash0 = crypt('abc'); // as (:encrypt abc:) would output
Hello. I discovered that PHP 5.3 builds for Windows have buggy crypt()
function, notably, passwords needed to be at least 4 characters. See
http://www.pmwiki.org/wiki/PITS/01141
If you use a longer password, does it work correctly?
I am open to ideas on how PmWiki should deal with this, while maintaining
backward compatibility with existing wiki pages and already encrypted existing
passwords.
Thanks,
Petko
Dominique Faure
> On Friday 04 June 2010 14:23:28, Peter Bowers wrote :
>> I am having difficulty with some authorization code on a WAMP server
>> and wondering if anybody can shed light...
>>
>> Here's what I've got in my config.php right now (minus comments):
>>
>> $hash0 = crypt('abc'); // as (:encrypt abc:) would output
>
> Hello. I discovered that PHP 5.3 builds for Windows have buggy crypt()
> function, notably, passwords needed to be at least 4 characters. See
> http://www.pmwiki.org/wiki/PITS/01141
>
> If you use a longer password, does it work correctly?
That's quite better (same code with a 6c. passwd):
D:\WebOnKey\phpbatch>phpbatch.cmd crypt_test.php
local config: 5.3.2
CRYPT_SALT_LENGTH: 123
hash0=$1$EV0.7d1.$gQfhWrt340ZnU7JUa72o7. (initial hash)
salt0=$1$EV0.7d1.$gQfhWrt340ZnU7JUa72o7. (salt as specified)
salt1=$1$EV0.7d1.$ (salt extracted)
hash1=$1$EV0.7d1.$gQfhWrt340ZnU7JUa72o7. (full hash)
hash2=$1$EV0.7d1.$gQfhWrt340ZnU7JUa72o7. (salt as specified)
hash3=$1$EV0.7d1.$gQfhWrt340ZnU7JUa72o7. (salt extracted)
D:\WebOnKey\phpbatch>phpbatch.cmd crypt_test.php
local config: 5.3.0
CRYPT_SALT_LENGTH: 60
hash0=$1$EM2.7I4.$ITCzP.cuaH4Lrvp.lRgZ.. (initial hash)
salt0=$1$EM2.7I4.$ITCzP.cuaH4Lrvp.lRgZ.. (salt as specified)
salt1=$1$EM2.7I4.$ (salt extracted)
hash1=$1$EM2.7I4.$ITCzP.cuaH4Lrvp.lRgZ.. (full hash)
hash2=$1$EM2.7I4.$ITCzP.cuaH4Lrvp.lRgZ.. (salt as specified)
hash3=$1$EM2.7I4.$ITCzP.cuaH4Lrvp.lRgZ.. (salt extracted)
D:\WebOnKey\phpbatch>
> I am open to ideas on how PmWiki should deal with this, while maintaining
> backward compatibility with existing wiki pages and already encrypted existing
> passwords.
At least, a warning in the auth form ?
--
Dominique
Dominique Faure
>> backward compatibility with existing wiki pages and already encrypted existing
>> passwords.
>
> At least, a warning in the auth form ?
BTW, since PmWiki only deals with hashed content, why not
systematically adding some constant padding chars to passwords before
hashing them? This could easily be done via the authuser's _crypt
function which should obviously be moved in the core.
Peter Bowers
> On Friday 04 June 2010 14:23:28, Peter Bowers wrote :
> Hello. I discovered that PHP 5.3 builds for Windows have buggy crypt()
> function, notably, passwords needed to be at least 4 characters. See
> http://www.pmwiki.org/wiki/PITS/01141
>
> If you use a longer password, does it work correctly?
Sure enough (as per Petko), if I change "abc" to "abcd" then
everything is fine. :-(
Similarly (as per Dominique) if I change back to PHP 5.2.11 then "abc"
works just fine. :-( But 5.3.0, 5.3.1, and 5.3.2 all gave me the
error under windows.
The problem does not appear to occur on linux platforms (as per Eemeli).
I've looked around unsuccessfully to find an existing bug report and,
in its absence, have reported it here:
http://bugs.php.net/bug.php?id=51996
If I've missed any details or something else that will be important to
getting it fixed, please comment there.
-Peter
Petko Yotov
> >> I am open to ideas on how PmWiki should deal with this, while
> >> maintaining backward compatibility with existing wiki pages and already
> >> encrypted existing passwords.
> >
> > At least, a warning in the auth form ?
Good idea.
> BTW, since PmWiki only deals with hashed content, why not
> systematically adding some constant padding chars to passwords before
> hashing them?
Because this will break all current passwords, even those that work on
sometning different than "less than 4 characters on PHP5.3/Win".
Md5() seems to work fine so in the past I was thinking that we could have our
function (_crypt?) test for the bug, and if crypt() appears to be broken,
automatically use the md5 hash (even if it is less secure). I never had the
time to work on this.
Petko
Patrick R. Michaud
> Md5() seems to work fine so in the past I was thinking that we could have our
> function (_crypt?) test for the bug, and if crypt() appears to be broken,
> automatically use the md5 hash (even if it is less secure). I never had the
> time to work on this.
Or even: ... if crypt() appears to be broken on the password being
encrypted/authenticated, add a constant string to it and try again.
Pm
Eemeli Aro
> I've looked around unsuccessfully to find an existing bug report and,
> in its absence, have reported it here:
>
> http://bugs.php.net/bug.php?id=51996
http://bugs.php.net/bug.php?id=49954
http://bugs.php.net/bug.php?id=50052
eemeli
Petko Yotov
> On Fri, Jun 4, 2010 at 4:50 PM, Petko Yotov <5...@5ko.fr> wrote:
> > On Friday 04 June 2010 14:23:28, Peter Bowers wrote :
> ...
> > Hello. I discovered that PHP 5.3 builds for Windows have buggy crypt()
> > function, notably, passwords needed to be at least 4 characters. See
> > http://www.pmwiki.org/wiki/PITS/01141
> >
> > If you use a longer password, does it work correctly?
>
> Sure enough (as per Petko), if I change "abc" to "abcd" then
> everything is fine. :-(
>
> Similarly (as per Dominique) if I change back to PHP 5.2.11 then "abc"
> works just fine. :-( But 5.3.0, 5.3.1, and 5.3.2 all gave me the
> error under windows.
Hello. Can you test the current code from subversion? Use _crypt() instead of
crypt(). The workaround is what Pm suggested earlier:
http://www.pmichaud.com/pipermail/pmwiki-devel/2010-June/001916.html
I just realize that while the workaround should work in broken PHP
installations, once these installations are upgraded and fixed, the saved
passwords may stop working. So, we should probably look for a better solution,
like simply telling people to have passwords of 4 or more characters.
Thanks,
Petko
Randy Brown
+----------------------------------------------------------------------+
| Creates an encrypted password that matches a regex pattern
| - masks user keystrokes
| - allows customizable prompts and messages (e.g. call the result an "Authorization code")
| - gets confirmation by asking the user to re-enter the password
+----------------------------------------------------------------------+
| Optional parameters:
| $Crypt2InclusionPattern is the regex pattern that a good password must match.
| Defaults to length >= 8, with at least 1 upper case letter, 1 lower case letter, and 1 number or special character
| $Crypt2ExclusionPattern is the regex pattern that a good password must not match.
| Defaults to anything containing whitespace
| $Crypt2InclusionMessage, $Crypt2ExclusionMessage, and $Crypt2MismatchMessage are the texts shown for user errors
| $Crypt2GoodMessage is the message shown when a good password is entered and confirmed
| $Crypt2Label is the text shown before the encrypted password. Defaults to "Encrypted password: "
| $Crypt2Prompt and $Crypt2Prompt2 are the prompts shown to elicit the password and its confirmation
| $Crypt2IntroMessage and $Crypt2CloseMessage are text that serve as a little header and footer, regardless of what happens
+----------------------------------------------------------------------+
| Note: This recipe is an adaptation of PmWiki's crypt script. It hasn't been well tested.
+----------------------------------------------------------------------+
On Jun 13, 2010, at 6:10 PM, Petko Yotov wrote:
>
> I just realize that while the workaround should work in broken PHP
> installations, once these installations are upgraded and fixed, the saved
> passwords may stop working. So, we should probably look for a better solution,
> like simply telling people to have passwords of 4 or more characters.