Practical Internet Groupware

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:

1. Use basic authentication to prove Aladdin’s identity by means of a directory ...