Item13404: HtPasswd AuthRealm changed for all users when one user is updated.
Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Detected and analysed during utf8 development (though it is unrelated).
When a password file is created using an md5 encoding, then the format of the file is auto-detected as htdigest-md5. This is incorrect.
The problem test (at least for me) is test_htpasswd_auto. It happens after line 503 when the encoding of the entries in the passwd file is md5 and the tests are switching to htdigest-md5. For me, the first couple of password changes work, because the passwd db is satisfied from the cache. On the third entry, however, there is a timeout on the passwd file and it is re-loaded from disc. When that happens, the encoding for the next entry is auto-detected as htdigest-md5. But it isn't, it's md5, so the checkPassword in setPassword fails.
This can't be worked around by changing the order of the encodings, because you will still end up with an md5-encoded entry being auto-decoded as htdigest-md5.
TBH I'm not sure why autodetection is used at all. Why not just add a field to the htpasswd file that records the encoding for each entry? e.g.
budgie:Another New Realm:730e83865b2f4d9eac83e2c903572f28:budgie@flock;budge@oz:md5
If the field is there, the encoding is obvious. If it isn't, then you can default to crypt or auto-detect.
Marking as urgent because autodetection isn't working, and for George's attention as this is his code.
--
CrawfordCurrie - 14 May 2015
Hi Crawford, Autodetect was added because it needed to be compatible with older htpasswd files, and possible shared htpasswd files as with foswiki.org and trunk.foswiki.org.
I guess I'm not following the error, we run autodetect on foswiki.org as we have a mixture of crypt, and apache-md5 encoding and it's been working well for a long time. Auto-detection is done during file load - line 284 - 367. I can't see how it could confuse htdigest. The file would have a Realm in the 2nd position, and not an encoded password. apache-md5, the 2nd position must be 37 bytes, beginning with the literal
$apr1$
If this is failing on utf8 tests, is something encoding or decoding the file so that the md5 string isn't 37 characters? The rules are very unambiguous except for plain text passwords, which we probably should not support. It's based upon the length and content of the 2nd field in the file: Tested in this order
Type |
Length |
Matches |
htdigest-md5 |
n/a |
$Foswiki::cfg{AuthRealm} |
(Realm has to be an exact match) |
sha1 |
33 |
^\{SHA\} |
crypt-md5 |
34 |
^\$1\$ |
apache-md5 |
37 |
^\$apr1\$ |
bcrypt |
60 |
^\$2a\$ |
crypt |
13 |
|
next field contains an email address |
plain |
any |
|
next field contains an email address |
sha |
|
|
(I don't recall what this encoding is, maybe an older implementation?) |
htdigest-md5 |
any |
|
Fallthru match in case realm changed |
I can't see how during file load, an apache-md5 entry could possibly be mistaken as htdigest-md5.
Ugh. That test was skipped due to missing dep. Now it's failing. Never mind. I'll try to figure it out it tomorrow night. These tests were passing at one point.
--
GeorgeClark - 15 May 2015
The tests pass on the Release01x01 branch, so we've diverged somehow.
It appears as though the changes made to address the password file corruption on Foswiki.org may be related. The Release01x01 version of the file doesn't have the issue, but the manually patched file on Foswiki.org, and the master version also fails. Indeed an urgent issue for 1.2
--
GeorgeClark - 15 May 2015
Ah. "encoding = md5" That's a completely obsolete configuration setting. Encoding = md5 is what we used to call digest encoding. it was mis-named. But was kept during save for compatibility with very old Foswiki configurations. I don't think that this is the cause of the test failure. We could probably just eliminated the check for encoding md5 in Foswiki 1.2.
--
GeorgeClark - 15 May 2015
The problem was in the password save code. When the file was re-written, all entries were changed to the current configured
{AuthRealm}
. Entries should be written out using whatever realm was used when hashing the password.
--
GeorgeClark - 17 May 2015