- From: Dave Kristol <dmk@allegra.att.com>
- Date: Fri, 24 May 96 14:49:18 EDT
- To: rdenny@dc3.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
"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
Received on Friday, 24 May 1996 11:57:30 UTC