Enable Auth Cookie Compression

[rasitha1]

Is your feature request related to a problem? Please describe.

Without session cookie compression, requests are unnecessarily large and even for a simple set of claims can reach the header size limits.

Describe the solution you'd like

Because of #79 and this default auth cookie compression was removed but I would like to humbly question was there enough testing done or security experts consulted to decide if this vulnerability is applicable to the .net implementation and this use case of session cookies? If yes, then aren't all Mvc5/Katana apps not have the same vulnerability?

Given the sign-in token is issued by a trusted token provider and signed, and therefore cannot be altered by the attacker as needed, couldn't you use one or all of the counter measures such obscuring the output size (using a padding mechanism) and obscuring the input size (by injecting randomly sized buffer at sign-in), etc. and still provide a safe implementation?

Additional context

Even if it's not enabled by default, if you can provide a proven and secure implementation that we can enable that will be very valuable.

Forcing a dependency on a backend storage just to store a simple set of claims, seems an overkill.

[blowdart]

Compression of user controlled, encryption data is a vulnerability waiting to happen (BEAST, CRIME etc)

Your assumption that the token can't be altered is incorrect. Take, for example, a facebook token. An attacker can change their profile name, and control what is sent. Injection of a randomly sized buffer is a mitigation, but the real solution is simply not to compress or to use reference cookies. This has not changed since issue 79. nor will it change.

[rasitha1]

Yes my assumption was that user controlled examples given in 79 such as the profile name were not enough for the attacker to see a difference esp. if a buffer was used.

However, if you strongly feel it's not safe or have the slightest (practical) possibility of introducing a vulnerability, I agree it's best for us to use another option.

You mentioned

Compression of user controlled, encryption data

In our use case, the majority of the claims are not user-controlled. At sign-in time, we look at the authorization tables and inject additional claims with permissions that the user has within the app. Those not user-controlled data. Do you think it's safe to use a separate compressed & encrypted session cookie for those and when auth ticket is reconstructed somehow inject those additional claims into the ticket/principal? That way user-controlled data is not compressed and limited to the sign-in claims.

[blowdart]

I'd use claims transformation for that and cache the results within your app for as long as you feel is appropriate.

[rasitha1]

For this "caching" of the results/claims in my app, is it safe to use a compressed & encrypted cookie?

[blowdart]

I would say no, put it in a redis cache or something that's kept server side and shared between instances.

[rasitha1]

Thanks for your input and direction. Much appreciated.