RE: Digest Authentication

IETF security policy is the reason why Digest is mandatory.

W3C policy is not going to accept sending passwords in the clear
either.

		Phill

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dylan Barrell
> Sent: Wednesday, October 17, 2001 9:22 AM
> To: WebDAV; Lisa Dusseault
> Subject: 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 Friday, 19 October 2001 21:50:32 UTC