

No More Passwords In The Clear in HTTP!

From: Daniel W. Connolly <connolly@hal.com>
Date: Mon, 09 Jan 1995 13:49:54 -0600
Message-Id: <9501091949.AA11478@ulua.hal.com>
To: www-talk@info.cern.ch, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

I just read a very interesting proposal:

From: "Electronic Commerce Standards for the WWW (Spyglass)"
Tue Dec  6 21:54:52 1994

|Simple Authentication - OPTIONAL
|This scheme, proposed by Spyglass, uses a random challenge sent from
|the server to the client. The client encodes the random challenge
|using the user's password as an encryption key in order to establish
|authentication. See Note B for a full specification.
|This method is currently indicated as OPTIONAL, but Spyglass believes
|that it should become REQUIRED for HTTP compliance.

This was something of an eye-opener. It's so simple. We should have
been doing this all along. There was never any reason to send
passwords in the clear (well, uuencoded), given HTTP's two-round-trip
authentication mechanism.

Why is this nifty proposal tucked away in a corner? Why didn't I hear
about it before now? I thought I was pretty tuned in to this sort of

For the longest time, I was under the impression that the web user
base would have two choices:

	1. Use a free browser, and access only public information, or
	send your password essentially in the clear to subscribe to
	for-pay info.

	2. Use a commercial browser that supports the security
	options (SHTTP, SSL, kerberos...) supported by the services
	you use.

The reason I believed this was that real security is to expensive to
develop to give away (and it almost always requires a license of some

As a result, information providers are faced with the unfortunate
choice between:

	1. Require users to send passwords essentially in the clear.

	2. Require users to license a browser.

This message is a call to eliminate passwords-in-the-clear from HTTP.
This means the browser developers should implement something like the
spyglass proposal (it looks like a few hours more work to upgrade to
this from the existing basic auth. scheme), and subscription-based
information providers should _strongly_ encourage their user base to
upgrade. Something like:

	"Please upgrade to a browser that doesn't send passwords in
	the clear (such as... links to recommended browsers.). In 6
	months, we will not be accepting Basic authentication."

I suggest that Spyglass lead the way by releasing source code patches
to lynx and Mosaic to implement this enhancement, just to show how
it's done. It should be a "simple" excercise for them.

Using high-quality services on the web should not be an incentive to
send passwords over the net in the clear. Let's fix this!


p.s. I hear s-key is another simple technology that eliminates the
need to send passwords in the clear. But for the life of me, I can't
find a technical description of it. Is there an RFC that I just can't
find? Could somebody send me a pointer?
Received on Monday, 9 January 1995 12:00:08 EST

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