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:

Then, amend the authorizing script to test for either basic authentication or cookie authentication:

if ( 
     isCookieAuthUserForCompany ( $cookie, $company          )  or
     isBasicAuthUserForCompany  ( $user, $password, $company ) 
   )

If isCookieAuthUserForCompany( ) finds a cookie named ProductAnalysis-Subscriber, and if it finds that cookie’s value in the database, it authorizes access—subject to the company-subscription test, that is.

If isCookieAuthUserForCompany( ) finds no cookie named ProductAnalysis-Subscriber, it fails and isBasicAuthUserForCompany( ) springs into action. If it authenticates the given username/password, it creates a cookie value, stores it in the database, sends the cookie back to the browser, and authorizes access—again subject to the subscription test.

How exactly this should work is a matter of policy. You might, for example, want to ask users whether or not they want your system to remember them. You might want to send cookies only to browsers on known subnets, so that colleagues working on borrowed laptops or from Internet cafes won’t leave access tokens lying around where they shouldn’t.

The database used in this approach creates an audit trail. If it shows that Aladdin authenticated from a subnet where Aladdin wasn’t, or on a date when Aladdin didn’t, you’ve got some security analysis to do and some evidence to work with.

When the cookie expires, Aladdin can acquire a new one by reauthenticating with his name/password. What expiration date should you choose when you set the cookie? As usual, it depends. You’re trading risk for convenience. The risk is that a cookie-configured browser that automatically accesses a protected docbase will fall into the wrong hands. The convenience is that when that browser is in the right hands, its user has easier access to the docbase. Further complicating matters, in this case, is the subscription aspect of authorization. If a subscription to a docbase expires, access will be refused no matter what the cookie says. There really isn’t a right answer here. A cookie is just a tool that you can use when it’s appropriate to do so.