What to Put in a Cookie and for How Long
Cookies often work hand in hand with basic
authentication, since you only want to plant a cookie on a browser
once you’ve authenticated the user of that browser. What
credentials should the cookie store? You could put a
username/password combination in a cookie, but that’s usually
not a good idea. If Aladdin:open sesame
authenticates Aladdin to a central directory, an unattended browser
or stolen cookie file could be really bad news. Instead, the cookie
value shown in Table 12.1—a
username/timestamp/subnet combination—merely remembers that
user Aladdin successfully authenticated to the
ProductAnalysis docbase from the stated subnet at the stated time.
What if you did store real credentials in the cookie but encrypted them? This only offers a marginal benefit. It’s true that someone who steals a cookie file is unlikely to be able to decode the value. But if the thief knows or can guess what resource the cookie authorizes access to, there is no need to decode anything. To the authorizing application, the cookie value is just an opaque token that it will match against some stored value. Remember: authentication doesn’t prove identity; it only proves that something on the other end of the wire is sending the credentials that you associate with an identity.
How can you authenticate and authorize with this username/timestamp/subnet cookie value? One approach is as follows:
Use basic authentication to prove Aladdin’s identity by means of a directory ...