- From: Nico Williams <nico@cryptonector.com>
- Date: Mon, 11 Feb 2013 10:36:53 -0600
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Zhong Yu <zhong.j.yu@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Mon, Feb 11, 2013 at 10:05 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > On Mon, Feb 11, 2013 at 10:24 AM, Nico Williams <nico@cryptonector.com> > wrote: >> (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. Heh, well, you know that I'm with you on this, as we both have I-Ds that involve the use of MACs to authenticate access to sessions on each request. > 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. Right. > 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. Although BEAST/CRIME are not the only reasons to want this. > So the communication pattern might be: But we still need a) a session ID, and/or b) server-side state stored as encrypted cookies (in the generic sense, not "web cookies") on the client side. Nico --
Received on Monday, 11 February 2013 16:37:26 UTC