RE: Digest Authentication

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