WebApp Sec mailing list archives
Re: Encrypted cookies
From: "Andy Steingruebl" <steingra () gmail com>
Date: Thu, 10 Jan 2008 15:46:53 -0800
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 -------------------------------------------------------------------------
Current thread:
- Encrypted cookies Ron (Jan 10)
- Re: Encrypted cookies Andrew van der Stock (Jan 10)
- Re: Encrypted cookies Andy Steingruebl (Jan 11)
- Re: Encrypted cookies Andy Steingruebl (Jan 10)
- Re: Encrypted cookies Lucas Oman (Jan 10)
- RE: Encrypted cookies Brokken, Allen P. (Jan 10)
- Re: Encrypted cookies Orlin Gueorguiev (Jan 11)
- <Possible follow-ups>
- Re: Encrypted cookies Rico Secada (Jan 10)
- Fw: Re: Encrypted cookies Rico Secada (Jan 11)
- Re: Fw: Re: Encrypted cookies Ron (Jan 15)
- Re: Encrypted cookies Andrew van der Stock (Jan 10)