- From: John Franks <john@math.nwu.edu>
- Date: Tue, 6 Jan 1998 16:58:51 -0600 (CST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Forwarded at Ben's request. John Franks john@math.nwu.edu ---------- Forwarded message ---------- Date: Tue, 06 Jan 1998 22:43:21 +0000 From: Ben Laurie <ben@algroup.co.uk> To: John Franks <john@math.nwu.edu> Subject: Re: Digest mess John Franks wrote: > > 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. Hmmm. That'll teach me to rely on my memory. I'd forgotten that the URL was in there. Certainly this reduces the problem. > 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. Right. > 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. Well... no less appropriate than Basic, and, in fact, somewhat more appropriate. If Digest is truly not appropriate for PUT or POST, then PUT and POST are not appropriate for HTTP (without some stronger authentication). > 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. You'd be wrong, if I recall correctly (but my record isn't too good so far). The current implementation was intended purely for interoperability testing. Since it was followed by a rush of non-implementation in clients, we never bothered to take it further. If we can decide what Digest really should be, and clients are actually going to implement Digest, then no doubt we'll do a better job. I'd like to see it done properly. Cheers, Ben. -- Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Received on Tuesday, 6 January 1998 15:03:23 UTC