Re: v11-03 COMMENT: (following) 19.1 Authentication of Clients

"Bob Denny" <> writes:
  > [...]
  > I consider this to be a serious flaw in offering a choice of authentication 
  > methods. Why do it at all? If the user EVER uses the weaker choice, his 
  > credentials have been exposed at that (lowest) strength. As you pointed out, 
  > offering stronger choices serves only to protect credentials anyway.
  > [...]
  > I believe that the server should require authentication at one strength only, 
  > as configured for the target object by the server or content administrator. 
  > This of course puts a roadblock in the way of implementing stronger methods 
  > (e.g., Simple MD5). If the server requires strong authentication and the 
  > browser doesn't support it, the user can't use the target object. 

Two observations:
1) We acknowledge that Basic and Digest are relatively weak.  Moreover, the
content is sent as plaintext anyway.

2) There's a transition problem that we need to solve.  If I have
content to serve that requires authentication, I would prefer to do it
with Digest instead of Basic.  But few browsers support Digest now, and
I have content I want to serve to everyone now.  Given that we
acknowledge that the authentication is weak and the content is
plaintext, what can I do?

The answer, an admittedly poor one, is to make it possible to accept
either and state a preference for Digest.  Offering the choice is
better than either just asking for the lowest common denominator
(Basic) or only accepting Digest and cutting off a large user base.

The spec. has to say what a client should do if there's more than one
challenge in a WWW-Authenticate.  The Appendix merely highlights the
flaws.  That's all it's intended to do.

Dave Kristol

Received on Friday, 24 May 1996 11:57:30 UTC