[cap-talk] Security considerations for cookies

[Adam Barth]

On Mon, Feb 15, 2010 at 11:21 PM, David Wagner <daw at cs.berkeley.edu> wrote:
> Adam Barth  wrote:
>>[[
>>Servers SHOULD encrypt and sign their cookies when transmitting
>>them to the user agent (even when sending the cookies over a secure
>>channel).
>>]]
>
> Hmm.  I wonder if this advice can be improved.
> Consider two alternate paradigms, which we could recommend:
>
> P1: Servers should encrypt and sign cookies.
> P2: Servers should store only a random unguessable ID in the cookie,
> and all state should be stored on the server, indexed by that ID.
>
> I think P1 has an additional security risk that is less likely to arise
> in P2: the risk of replay attacks.  So, to me, P1 seems like it might be
> harder to secure: i.e., it seems like if we want to explain to developers
> how to use P1 securely, the list of things we have to explain is longer
> than if we recommend P2.
>
> (Yes, replay attacks could occur in P2 if developers added new IDs
> and entries to the state table instead of mutating the entry associated
> with an existing ID, but I conjecture that this kind of mistake is
> less likely, because developers are used to updating entries in
> hashmaps as time passes.)
>
> This makes me think it may be better to recommend that developers
> follow approach P2.  What do you think?

I think it depends on what you think the goals of the Security
Considerations section are.  My understand is that it serves two
purposes:

1) It's CYA for the IETF.  If something goes wrong, the IETF doesn't
want to be blamed.  They want to point to the security considerations
and say "look, we told you that wasn't a good idea."

2) It's a resource for folks who want to use the protocol securely.
By listing all the things we know are wrong with the protocol and
recommending mitigations, folks can use that information to build more
secure systems.

Purpose (1) pushes us to be as ridiculous and draconian as possible.
The more we tighten down the recommendations, the better CYA we get.
However, purpose (2) pushes us to recommend things that folks might
actually want to implement.

Returning to the issue at hand, I don't think that everyone is going
to switch to using cookies exclusively as hash keys.  For example,
ASP.NET exports all its server-side state to the client in an
encrypted-and-MACed cookie.  They do this to avoid having to keep
per-user state on the server, making ASP.NET services scale better.

I'd rather recommend that all cookies be encrypted and MACed so that
folks build that into frameworks rather than trying to draw fine
distinctions between which things can be stored "in the clear."
Recommending that servers always encrypt-and-MAC (conveniently) serves
both purpose (1) and (2).

Adam