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

Re: more on Digest Auth

From: John Franks <john@math.nwu.edu>
Date: Wed, 21 Feb 1996 17:35:08 -0600 (CST)
To: Ned Freed <NED@innosoft.com>
Cc: dmk@allegra.att.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960221170508.9736B-100000@hopf.math.nwu.edu>
On Wed, 21 Feb 1996, Ned Freed wrote:

> > In my implementation (based on John Franks's), the server expects the
> > returned opaque string to match one it can calculate from the other
> > parameters.  I don't claim to be a security or crypto expert, but I
> > think an adversary would have a hard time predicting what the opaque
> > string should be, because of the compile-time random number, if not the
> > timestamp.
> 
> They don't have to predict it, the server will give it to them any time they
> want it. The WWW-Authenticate response from the server includes the opaque
> string that is supposed to be used in the next access attempt. So all they do
> is take this value, and as long as the nonce value it includes is one that
> they've snooped off the wire and know the digest for, they are all ready for a
> nice little replay attack on the server. The point is that the opaque
> string doesn't have to match the one that was previously used by the client
> since it didn't influence the digest.
> 

I think the opaque in a replay attack does have to match the opaque
which was previously used by the client because the opaque contains a
hashed version of the nonce and the digest includes a hashed version
of the nonce.  So the server checks that the nonce, digest and opaque
in a request are all compatible.  The attacker knows the nonce but
can't compute the digest without the client's password and can't
compute the opaque without the server's secret key.

Of course, the attacker can snoop the client's transmission of nonce,
digest and opaque.  It can then do a replay attack *if* it can spoof
the client IP address.  This means not only convincing the server that
the attack request is coming from the client's address but getting the
server to return the document to the attacker while believing it is
returning the document to the client.  This can only be done while the
timestamp has not expired.

Keep in mind that the URI is also hashed into the digest.  So the replay
attacker can only get the same document which the client got when it
was snooped.  Since this document was not encoded it would be *much*
easier for the attacker just to grab the document in the original snoop.

So yes, a replay attack is possible.  There just isn't much point.  

It is important to keep a little perspective here.  No one has ever
suggested this protocol for banking transactions or for any
transaction which requires encrypted content going either way.  In
particular it cannot be used for any kind of credit card transaction.
The kind of thing it might be useful for is selling subscriptions to
an online database and restricting access to subscribers.  Then if I
manage to snoop on your transactions I would be able to view the
responses to your queries (and I wouldn't need replay to do it), but I
would not be able to make any queries of my own.

With Basic Authentication, on the other hand, once I snoop your
password I can make as many queries as I want and have them all added
to your bill if it is a pay per view service.  It is this kind of thing
which is really the point of Digest Authentication.


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Wednesday, 21 February 1996 15:38:25 EST

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