No More Passwords In The Clear in HTTP!

Daniel W. Connolly ([email protected])
Tue, 10 Jan 1995 01:03:19 +0100


I just read a very interesting proposal:

From: "Electronic Commerce Standards for the WWW (Spyglass)"
http://www.spyglass.com/techreport/stdsec.htm
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
thing...

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
kind...).

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!

Dan

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?