Re: v11-03 COMMENT: (following) 19.1 Authentication of Clients
Dave Kristol (dmk@allegra.att.com)
Fri, 24 May 96 14:49:18 EDT
"Bob Denny" <rdenny@dc3.com> 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