- 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
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. > [snip] > 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 john@math.nwu.edu
Received on Tuesday, 6 January 1998 13:52:12 UTC