[unisog] Using cookies for authentication
gts at uclink.berkeley.edu
Sat Mar 8 03:53:40 GMT 2003
If an attacker has access to the client system, then there is pretty much
nothing you can do since that attacker can do anything that the user can do.
This is limited only by access controls on the client system (and the
ingenuity of the attacker).
However short of that, rather a lot of security can be had with simple
(but necessarily multiple) methods. You are already using non-persistent
cookies (congratulations this is very often overlooked!) and are working
over an SSL connection. Your cookie has a time stamp and is apparently
using a signed hash.
Next, as has already been suggested, use the time stamp to limit the
lifetime of the cookie. This works best if the time is short, as in
minutes. For longer times you can send updated cookies. This is
pretty much how our CalNet authentication service works.
It is hard to go further without much more specific detail about your
application and any extensions envisioned over time.
There is one technique that I have not heard anyone say they have
implemented, but with which I have experimented. Use the SSL session ID.
If you put the SSL session ID in your cookie and check for it on requests,
it would seem hard (in real time) for an attacker to hijack the activity.
Testing so far shows that browsers will maintain the same SSL session for
an ongoing activity with a server, however I have not researched the
standards (if any) that might say what a browser is supposed to do. This
of course assumes that authentication occurs with the same server and
session as the activity, or that on initial contact the initial cookie is
updated for the duration of the authorized activity.
Greg Small gts at uclink.Berkeley.EDU
Security Infrastructure Project On a network, paranoia is
WSS Security Officer just good thinking!
Workstation Software Support WSS/IST Systems Programmer for 35
University of California at Berkeley years and it's still fun!
At 01:26 PM 3/7/2003 +1300, Russell Fulton wrote:
> We are currently looking at a new web based application that uses
>cookies for authentication. The cookies contains amongst other things,
>userid, issue time, the issuing system ID and a SHA1 hash of the
>contents (and a secret) to prevent one changing the cookie. All
>exchanges of the cookies over the network are via SSL and the cookie
>also had flags that tell the browser not to write it to disk.
>So far as I can tell if an attacker can steal a cookie then they can use
>it to impersonate the cookie's owner for the lifetime of the cookie.
>We are try to do a risk analysis of this system and so I am trying to
>figure out how easy (or otherwise) it is to steal memory based cookies
>from systems running common browsers (mostly IE, some old :( ).
>Two schemes that occur to me are 1/ to tamper with the browser (so it
>writes the cookie to disk or better still sends it directly to the
>attacker) or 2/ to introduce malware on the the user's computer that
>will search for the cookie in memory and send it to the attacker. If an
>attacker has the ability to do either of these things then they could
>probably also install keyboard loggers and grab the users credentials
>directly -- something that affects almost all authentication systems so
>I am ignoring this for this particular exercise.
>What I am really focusing on is the risk of browser bugs and XSS bugs
>that might allow the cookie to be stolen. We must assume that the
>attacker may have a web server under their control in the same domain as
>the cookie and that they may be able to induce users to visit the site.
>Any thoughts or references gratefully received.
>Russell Fulton, Computer and Network Security Officer
>The University of Auckland, New Zealand
>"It aint necessarily so" - Gershwin
More information about the unisog