- From: David Jablon <dpj@world.std.com>
- Date: Wed, 06 Aug 1997 09:00:28 -0400
- To: John Franks <john@math.nwu.edu>, Phillip Hallam-Baker <hallam@w3.org>, Jeffery Hostetler <jeff@spyglass.com>, Paul Leach <paulle@microsoft.com>, Ari Luotonen <luotonen@netscape.com>, Eric Sink <eric@spyglass.com>, "Lawrence C. Stewart" <stewart@openmarket.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Gentlemen, I support your goal of replacing the clear-text password method in HTTP with something stronger, but I wonder about why you didn't consider something stronger. Several password-based protocols are known that are much better than the one described in this document: > Title : An Extension to HTTP : Digest Access > Authentication > Author(s) : J. Franks, A. Luotonen, P. Leach, J. Hostetler, > P. Hallam-Baker > >The protocol referred to as 'HTTP/1.0' includes the specification for > a Basic Access Authentication scheme. This scheme is not considered > to be a secure method of user authentication, as the user name and > password are passed over the network as clear text. A specification > for a different authentication scheme is needed to address this > severe limitation. This document provides specification for such a > scheme, referred to as 'Digest Access Authentication'. Like Basic, > Digest access authentication verifies that both parties to a > communication know a shared secret (a password); unlike Basic, this > verification can be done without sending the password in the clear, > which is Basic's biggest weakness. ... So far, the above introduction seems good. > ... As with most other authentication > protocols, the greatest sources of risks are usually found not in the > core protocol itself but in policies and procedures surrounding its > use. However, this last sentence seems like an attempt to justify use of a weak method, and as such it ignores the fact that relative risks vary greatly in different situations. It may very well be the case that the "greatest sources of risk" *are* in the core protocol as described, *and* can be prevented by an ammended proposal. Only some of these risks are discussed in the document, and no mention is made of stronger protocols that can solve such problems. This seems inappropriate for a document focused on security issues. FYI, the site at <http://world.std.com/~dpj/> describes several modern password protocols. -- David
Received on Wednesday, 6 August 1997 06:00:18 UTC