Re: Encrypted cookies

[Andrew van der Stock <vanderaj () greebo net>]

Business requirements to not store the details on the server  
necessarily increases the risk of the attack.

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.

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.

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.

4. Key rotation

If the keys are discovered or you're just practicing sane key  
management, you'll need to rotate the keys. Imagine if the key doesn't  
decrypt the cookie. Could be an attack, could be real, but state key.  
This is not the end of the world, but you need a method of detecting  
the key change, rather than sending the user to a rather nasty "YOU  
HAXXOR YOU! WAIT THERE WHILST THE POLICE BUST DOWN THE DOOR" screen.

A simpler method, which protects the authentication credentials, is to  
generate a simple random number and use that as a key to a proper  
server side session management scheme. Oh look, that's exactly how  
session IDs work!

My message to the team is very simple:

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.

thanks,
Andrew


On Jan 10, 2008, at 11:26 AM, Ron wrote:

> Somebody here is developing a Web application that requires user  
> logins, but that is unable to store session information on the  
> server (don't ask me why, it's a long story). So here's what they  
> propose: to take the username, hash of the password, and date the  
> user logged in, encrypt them with a strong encryption algorithm, and  
> store them in a cookie (along with a hash to ensure integrity).
>
> My question is, assuming a proper encryption algorithm/eky are  
> chosen, can anybody think of a problem that this will create that  
> sessions don't already have (namely, replay attacks)?
>
> I've thought about this for over a day, and I can't think of any  
> obvious problems, but I could be missing something.


-------------------------------------------------------------------------
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
-------------------------------------------------------------------------