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
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
2. Use a commercial browser that supports the security
options (SHTTP, SSL, kerberos...) supported by the services
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
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?