Although
cookies have become a major
Internet cause célèbre, there
really isn’t much difference between name/password-based and
cookie-based authorization. In both cases, the browser transmits
credentials to the server by way of an HTTP header—it’s
either HTTP_AUTHORIZATION or
HTTP_COOKIE. In both cases, security is weak when
credentials travel over an unencrypted connection and much stronger
when the data is encrypted with SSL. In both cases, authentication
can persist so that users need not repeatedly assert their
identities. The chief advantage of the cookie method is also its
worst public-relations problem: cookies persist across browser
sessions. (With basic authentication, credentials persist only during
a session.) A cookie enables a server to recognize a user and
authorize access automatically, without any input from the user. In
order to do that, cookie data has to live on your hard disk.
We’ll review what that data is, how it gets onto your hard
disk, and how it can be used. But first let’s frame this
volatile issue with a few observations:
- Any form of authentication does away with anonymity.
Large areas of the Internet are open to anonymous use and will likely remain so. Groupware, though, is about relationships, and relationships are based on identity. If you choose to participate in a groupware application—on a public Internet site that serves 300,000 magazine subscribers or on an intranet server that hosts a team of a dozen collaborators—you must be willing to identify yourself. From this perspective it makes no difference whether you announce your identity by way of an
HTTP_AUTHORIZATIONheader or anHTTP_COOKIEheader.- Privacy depends on honor and trust.
When you give up your anonymity, you also lose absolute control of your privacy. All your actions and behavior in an authenticated realm can be monitored. At issue is whether, or to what degree, you actually are monitored and how the information collected about you will be used. Ideally an authenticated service should invite you to specify what you will allow it to remember about you, explain how what it remembers will help you, and state whether that information will be released and, if so, to whom and on what terms. Users who participate in authenticated services place their trust in these kinds of agreements. Providers of authenticated services have to honor the terms of these agreements. Again, though, this has nothing to do with cookies. The issue is authentication itself and its implications, not the means of authentication.
- Offer multiple means of authentication.
Despite these arguments, a lot of people just plain hate the idea of cookies. Why fight that? If someone thinks that a cookie is a kind of virus (it isn’t), you’re not likely to be able to change that perception, and there’s really no reason to try. Offer basic authentication as an alternative. We’ll see shortly how you can use both methods in parallel.