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

Re: Digest mess

From: John Franks <john@math.nwu.edu>
Date: Tue, 6 Jan 1998 15:49:48 -0600 (CST)
To: Ben Laurie <ben@algroup.co.uk>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.96.980106153416.1605A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5085
On Tue, 6 Jan 1998, Ben Laurie wrote:

> How does the server know the client has responded with the nonce the
> server sent? This requires a pile of mechanisms Apache hasn't got, or
> some way of recreating the same nonce.
> The attack in Basic is "snarf the password and then use it for your
> own evil purposes". The equivalent attack in Digest is "snarf the nonce
> and the hashed password+nonce and use it for your own evil purposes".
> That is a replay attack. The defence is to know that the nonce is a dud.
> The question is, how?

What the server receives is more complicated than what you describe;
it includes a  hash of username, password, method and requested URL.

So, you are right, that a MITM could replay a request, but only for
exactly the same URL with the same method.  This means it is quite
appropriate for use with GET (or another idempotent method) as the MITM
could only get another copy of a document he had already seen.

Digest without the optional entity-digest (as in Apache) is
inappropriate for PUT or POST, in any case, as there is no way to know
that a MIM has not tampered with the posted entity.

Incidentally, I don't know about Apache, but many implementations
give a nonce a short duration time-to-live.  A good implementation 
would at least encode the last modified date in the nonce to assure
that a replay cannot get an updated version.  This is pretty easy
and I would assume Apache does it.

John Franks
Received on Tuesday, 6 January 1998 13:52:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC