Re: Encrypted cookies

["Andy Steingruebl" <steingra () gmail com>]

On Jan 10, 2008 2:13 PM, Andrew van der Stock <vanderaj () greebo net> wrote:
> Business requirements to not store the details on the server
> necessarily increases the risk of the attack.

Andrew -  I remain unconvinced that with proper key rotation policies
this is necessarily more risky than someone brute forcing the private
half of the SSL keys - that is, not likely.  Assuming equivalent
quality of implementation, etc.

> 1. Spoofing authentication
>
> If all users have the same encryption key, which bedeviled .NET 1.0 /
> 1.1 ViewState, means that it might be possible to brute force your way
> through the user dictionary in much less time based upon basic HTTP
> responses.

Explain please?  Sure you can do a known plaintext attack against the
system as its deliberately set up to be an oracle, but I'm not sure I
see where you're going with this.  Any of these schemes needs to
robust against offline attacks.  if you're using a crypto scheme that
isn't going to be robust against an offline attack you've done it
wrong.  Assuming you have, then my comment from above applies.
Attacking the private key of the SSL session, or the key of the cokie
encryption ought to be roughly equal in work factor. Both attacks can
be done offline, and you ought to be robust against either.

> 2. Long term replay
>
> I do not see any expiring of the credential, just the time it was last
> logged in. This means that a credential blob created today would still
> be valid at some arbitrary point in the future. This means if I have
> access to the cookies via some mechanism, I can come back at any time
> later. If you make this 20 minutes, like a session identifier, you're
> back to the strength of the session identifier, in which case you
> shouldn't do this scheme.

Sure, but again this isn't inherently a limitation of the cookie and
the data, we have plenty of data in the cookie to tell whether a
credential is "fresh" even if we don't include an expiration.  In
either case the server either as to check when the cookie was minted
and know whether its still valid, or it has to read the expiration
time.  Both will work, but per my previous note I do agree that
including an expiration time ought to be a good practice.

> 3. Potential identity theft
>
> If the attacker obtains or cracks the key (unlikely but possible -
> depends on PRNG and key generation issues), the site's authentication
> mechanism is blown wide open.

I think this still reduces to #1 above. Maybe you didn't good key
generation when you generated your SSL keypairs, maybe you didn't have
a good session key in SSL.  All of these are implementation not
architectural issues.  Are you saying these are *that* much harder to
get right?

> 4. Key rotation

Here I'll agree with you - this is going to be the trickiest part of
the whole operation.  A lot of folks though have had to get better at
this lately anyway though because of things like PCI and its
requirements for key rotation for long-term stored secrets. So, while
this is tricky, people doing any sort of financial app these days will
have to have this, so for those folks its probably less of an issue.

> It's 2008, stop writing session managers already! It's 3000-15000
> lines of code and $20-100k you just don't need to code and review.
> It's exactly like getting $100k in nice shiny notes and setting fire
> to it. Nice to look at for a few minutes, but utterly worthless in the
> long run.

I think the problem is that there are valid cases where people don't
want to maintain user session state on the server.  All of that
requires overhead as well, especially for folks with large and
geographically distrubuted server footprints.  For those folks storing
as little login session state as possible and not having to hit that
datastore for every webhit is going to be an advantage.

--
Andy Steingruebl

-------------------------------------------------------------------------
Sponsored by: Watchfire 
Methodologies & Tools for Web Application Security Assessment 
With the rapid rise in the number and types of security threats, web application security assessments should be 
considered a crucial phase in the development of any web application. What methodology should be followed? What tools 
can accelerate the assessment process? Download this Whitepaper today! 

https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------