- From: Ned Freed <NED@innosoft.com>
- Date: Wed, 21 Feb 1996 14:09:57 -0800 (PST)
- To: dmk@allegra.att.com
- Cc: NED@innosoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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. The solution, of course, is to put all your good unpredictable stuff into the nonce value rather than the opaque string. Implementation change, not protocol change. Ned
Received on Wednesday, 21 February 1996 14:17:49 UTC