- From: Dylan Barrell <dbarrell@opentext.com>
- Date: Wed, 17 Oct 2001 09:22:03 -0400
- To: "WebDAV" <w3c-dist-auth@w3.org>, "Lisa Dusseault" <lisa@xythos.com>
Ah, right. It does get a bit complicated: Yes, the concern is the storage of H(A1), because this is a plaintext-password equivalent. The only advantage to storing H(A1) over the plaintext password itself is that leaking the "password file" wouldn't compromise other systems on which the user uses the same password. Apart from that, it's the same as a plaintext-password, because you can use it to log in as the user in question. Livelink stores its "password file" in the database, and it does _not_ assume that anyone who can access the password info has the right to impersonate any user. The way Livelink stores this information ensures that you cannot impersonate a user with it. This is a feature of _many_ authentication mechanisms, including the old /etc/passwd. Right now, we can have a very secure Livelink install by using SSL with Basic authentication. If we must support Digest authentication, however, then it would seem that we need to store H(A1), and so we would be introducing a hole that does not exist Today -- bad. You see, the problem is not so much that the spec forbids us from offering Basic over insecure channels (though I would argue that it is overly presumptuous). The significant problem is that the spec _insists_ that we support Digest -- even if we only use secure connections. The only way I can see implementing Digest without introducing this new security hole is to use a constant server nonce and no qop, so that for any username/password/realm, the request-digest is constant. Then I can store salt+H(salt,request-digest) in the database. While this _would_ produce a compatible implementation, it would violate several directives in rfc2617, and would render the protocol vulnerable to sniffing again -- just like Basic. Hence my request to demote digest authentication to the same level as basic i.e. optional.
Received on Wednesday, 17 October 2001 09:23:37 UTC