W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Proposed revision to security considerations

From: John Franks <john@math.nwu.edu>
Date: Sun, 24 Mar 1996 20:18:24 -0600 (CST)
To: jg@w3.org
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960324201354.23774B-100000@hopf.math.nwu.edu>

Attached is my revised version of section 14.1.  This is the section
of the spec dealing with security considerations and authentication.

If the digest authentication document "docks" with the HTTP/1.1 spec
then its security considerations should perhaps dock with this one.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu


14.1 Authentication of Clients

As mentioned in Section 11.1, the Basic authentication scheme is not a
secure method of user authentication, nor does it in any way protect
the Entity-Body, which is transmitted in clear text across the
physical network used as the carrier. HTTP does not prevent additional
authentication schemes and encryption mechanisms from being employed
to increase security or the addition of enhancements (such as schemes
to use one-time passwords) to Basic authentication.

The most serious flaw in Basic authentication is that it results in
the essentially clear text transmission of the user's password over
the physical network.  It is this problem which Digest Authentication
attempts to address.

Because Basic authentication involves the clear text transmission of
passwords it should never be used (without enhancements) to protect
sensitive or valuable information.

A common use of Basic authentication is for identification purposes --
requiring the user to provide a username and password as means of
identification, for example, for purposes of gathering accurate usage
statistics on a server.  When used in this way it is tempting to think
that there is no danger in its use if illicit access to the protected
documents is not a major concern.  This is only correct if the server
issues both username and password to the users and in particular does
not allow the user to choose his or her own password.  The danger
arises because naive users frequently reuse a single password to avoid
the task of maintaining multiple passwords.

If a server permits users to select their own passwords, then the
threat is not only illicit access to documents on the server but also
illicit access to the accounts of all users who have chosen to use
their account password.  If users are allowed to choose their own
password that also means the server must maintain files containing the
(presumably encrypted) passwords.  Many of these may be the account
passwords of users perhaps at distant sites.  The owner or
administrator of such a system could conceivably incur liability if
this information is not maintained in a secure fashion.

Basic Authentication is also vulnerable to spoofing by counterfeit
servers.  If a user can be led to believe that he is connecting to a
host containing information protected by basic authentication when in
fact he is connecting to a hostile server or gateway then the attacker
can request a password, store it for later use, and feign an error.
This type of attack is not possible with Digest Authentication.
Server implementors should guard against the possibility of this sort
of counterfeiting by gateways or CGI scripts.  In particular it is
very dangerous for a server to simply turn over a connection to a
gateway since that gateway can then use the persistant connection
mechanism to engage in multiple transactions with the client while
impersonating the original server in a way that is not detectable by
the client.
Received on Sunday, 24 March 1996 18:22:34 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:49 EDT