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
-------------------------------------------------------------------------
Received on Jan 10 2008
Intro
