[302] in WWW Security List Archive
Re: No More Passwords In The Clear in HTTP!
daemon@ATHENA.MIT.EDU (hallam@alws.cern.ch)
Sat Jan 14 04:43:12 1995
From: hallam@alws.cern.ch
Date: Tue, 10 Jan 1995 16:07:20 +0100
X-Vms-To: DXMINT::http-wg-request@cuckoo.hpl.hp.com,DXMINT::www-security@ns1.rutgers.edu,DXMINT::www-talk@www0.cern.ch,
Apparently-To: <www-talk@www0.cern.ch,>
Apparently-To: <www-security@ns1.rutgers.edu>
Apparently-To: <http-wg-request@cuckoo.hpl.hp.com>
Reply-To: www-security@ns2.rutgers.edu
Hi folks,
sorry about the multiple lists business, but this has leaked across
boundaries...
The Spyglass scheme is pretty much the same as the one I proposed in Shen with
minor modifications. I did use the S-Key scheme initially but decided against it
and now use a slightly different form. I have been reimplementing it as part of
the process of implementing S-HTTP, If people like I can try to get some code
out by the end of the Week - no the beginning of the next week. It is written
but not completely tested, runs on the CERN server and on the Linemode browser.
We should be discussing this on the security list BTW...
>>>> MAILTO:www-security-request@ns1.rutgers.edu
I think we need to separate levels of abstraction here, first there is the idea
of using an MD5 hash, second there is the implementation idiom. On the
implementation idiom the winner is Alan Shifman of EIT, both he and I suggested
implementation idioms for security in HTTP. Without wanting to reopen that
debate it turns out that Alan picked the right solution, I had tried as far as
possible to stay within certain constraints set by HTTP, Alan decided to work
with a bit more freedom. Judging the results I don't think that keeping the
restrictions is worth the candle, the advantage gained is illusory it turns out.
Really we should not be talking about S-HTTP anymore, it is really HTTP/2.0 or
something, except that there are some changes that I would like to see in the
negotiation mechanism to make it a general one. Really S-HTTP as a name is an
abreviation for "Security ideas form EIT".
One other point, the scheme can also be used to do encryption without involving
RSA. If the password has got to the other end OK then it can be used as a
symmetric encryption key.
OK now for the technical issue, S-Key vs Digest method?
1) Common Definitions,
Let D(x) be a digest function
Let P be the known password.
2) S-Key,
Parameters: Let n be an integer.
Initialisation:
Server calculates test value T = D^n(P) and stores it together with a count, C
which is initialised to 0
Client, stores value of count, 0.
Application: Client cacluates K=D^(n-C)(P), Server calculates D^C(K) which
should match T. C is incremented, if C>P a new password is needed.
3) Digest,
Server calculates diest of password, DP = D(P)
Client - no calculation.
To send a message, M the value K = D(M, DP) is calculated. The server matches
this with the password in the database.
Comparison,
S-Key Advantages,
No password is stored in plaintext.
Password is never communicated in the clear.
It is actually used in some dongle type systems (ask TIS!)
S-Key Disadvantages
The mechanism is not idempotent, this is a big problem when a forking server is
used (eg the CERN one). Under UNIX there is no method of reliably updating the
password database with the new value of the count. With threads this is not the
case. Implementation of this scheme would require a major rewrite of the CERN
server and many others. This being the case I'm not too happy with using it for
a `simple' scheme.
The mechanism also breaks down if several requests are generated and handled in
a different order. Eg Netscape server toasting mode when loading multiple gif
files at once. This problem also occurs in normal usage - eg have a query on a
server that is taking some time and pop a few extra requests in at the same
time.
Communicating the original password is a problem.
Possible problem with certain faulty hash functions. Repeated recursive
application may turn up some sort of locus of attraction problem meaning that
D^n(X) = D^n(Y) with a frequency dependent on n. This sort of thing is unlikely
to occur in the range suggested by Lamport (100 ish) but I would be worried,
particularly with MD5 for reasons I go into later.
The original scheme was designed for login type applications. HTTP works at the
request level so there are many more communications - thousands a day in fact,
each time I read an email I am generating a new HTTP transaction (hands off -
not finished yet BTW).
Digest Advantages,
Password is never communicated in the clear.
Digest Disadvantages
The user password is not stored in plaintext but the digest of the pasword DP is
all that is actually required. This may seem a major hole but the same risk is
actually present with public key schemes where an authentication signature is
stored in the machine itself.
Communicating the original password is a problem. As with S-Key there is still
an advantage to using RSA etc.
Modifications,
--------------
Actually both schemes should be slightly modified in the following manner,
instead of using the password P it is better to use a composite of the Password,
username and server to form the Digest root.
Proposal,
---------
First off MD5 is not such a good hash function, problems with the compressor.
SHA is much better for this purpose. Main point is it must be selectable which
means that S-HTTP type negotiation is a factor.
Incorporate an S-Key mode into S-HTTP. I am quite happy to do client side
implementation and server side hooks but as previously stated I can;t do a
usefull scheme with the CERN server if its going to be forking. Even without
forking it would be a major hassle for many other implementors. Actually there
is a major hassle for some clients as well (not Arena or the linemode.
To do this the easiest mode would be to simply integrate it as a variant of the
current digest scheme.
Phill H-B
