On Mon, Feb 11, 2013 at 10:24 AM, Nico Williams <nico@cryptonector.com>wrote: > On Mon, Feb 11, 2013 at 1:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > > I really don't see why it should be the clients problem to store > > the servers state. > > > > If somebody needs 8k of storage for each browser that visits their > > website, they can bloody well buy their own disks... > > It's a common implementation pattern. I'm not ready to tell > application implementors to stop doing this. > > It's not just the disk space, but also the need to fetch it and the > need to distribute it across related servers. Using the client to do > this has some benefits. > > (Also, a note about small session IDs: they can't be so small as to be > guessable. 32-bit session IDs would be a disaster. I think I'd not > feel comfortable with session IDs smaller than 96-bits.) > Please, lets not repeat the mistake of doing bearer tokens. I would very much like to separate out authentication tokens from state tokens so that we can get some sanity. But the replacement for the use of a session cookie for authentication should be a proof of knowledge of the shared secret rather than presentation of the shared secret itself. Doing this would render the various BEAST and CRIME attacks ineffective along with most cookie stealing as the confidential data would only go across the wire in plaintext at most once. So the communication pattern might be: Client: Request 1 Server: Authentication key is XY3i9dij993==, NonceS is 299w3i34= Client: NonceC is 299eu393=, NonceS is 299w3i34=, MAC (XY3i9dij993==, 299w3i34=, 299eu393=) Server: NonceS is w8828w9w==, NonceC is 299eu393=,, MAC ( ... ) The basic idea being that the key only goes across the transport once and both sides are responsible for encoding sufficient checksum info into their nonces as to be able to check for freshness. Alternatively a counter could be used (etc. etc.). -- Website: http://hallambaker.com/
Received on Monday, 11 February 2013 16:05:38 UTC