You are here: Foswiki>Tasks Web>Item13404 (05 Jul 2015, GeorgeClark)Edit Attach

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
Applies To: Engine
Component: HtPasswdUser
Branches: master
Reported By: CrawfordCurrie
Waiting For:
Last Change By: GeorgeClark
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 and

I guess I'm not following the error, we run autodetect on 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 may be related. The Release01x01 version of the file doesn't have the issue, but the manually patched file on, 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

ItemTemplate edit

Summary HtPasswd AuthRealm changed for all users when one user is updated.
ReportedBy CrawfordCurrie
Codebase 1.2.0 beta1, trunk
SVN Range
AppliesTo Engine
Component HtPasswdUser
Priority Urgent
CurrentState Closed
Checkins distro:57b255a72fe7
TargetRelease major
ReleasedIn 2.0.0
CheckinsOnBranches master
masterCheckins distro:57b255a72fe7
Topic revision: r4 - 05 Jul 2015, GeorgeClark - This page was cached on 18 Sep 2021 - 01:02.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy