- From: John Franks <john@math.nwu.edu>
- Date: Thu, 22 Feb 1996 12:02:01 -0600 (CST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 21 Feb 1996, Paul Leach wrote: > John said -- > > ] I didn't carefully follow your nonce incrementing proposal, but the > ] only way I can immediately see to make it useful in preventing replay > ] attacks is for the server to keep a data base of used nonces and the > ] number of times each has been used. Otherwise the server wouldn't > ] know if the nonce had been properly incremented each time. Keeping > ] this data would constitute a "very big change" for a large heavily > ] loaded server. > > I posted the 47 lines of code it takes to detect reuse of nonces. The > most expensive operation was hashing (not digesting) the username and > password. I'll time it tomorrow -- I'll bet it doesn't take more than > 20 microsecs on a 100 mhz pentium. > > So I don't think it's a "very big change". > > Okay, let's stipulate, for the sake of argument, that you can efficiently remember which nonces have been used. Then why not just use a new nonce for each transaction (a strategy suggested by the specification). That wouldn't break anything and would achieve your goal of defending against replay attacks. I hope everyone understands that a new nonce does not mean that the user must re-enter her username/password. It only means that if the client tries with the old nonce it gets a message that the nonce is stale and it is asked to re-authenticate using a new nonce. All this is transparent to the user. The username and password have to be remembered by the client anyway. There is a slight increase in net traffic because of the extra transaction. But this is really a marginal difference, especially with persistent connections. One of the nice things about the current spec is its flexability. For your application one-time nonces may be crucial. But for mine nonces with a one hour timestamp may be more appropriate. Both of these are possible. Neither has to be set in stone in the protocol. It is true that incompetent implementations are possible which would not be secure. But that will always be true no matter what we put in the specification. John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Thursday, 22 February 1996 10:05:30 UTC