You may not have thought of cookies as an identity credential; but, the fact is, they represent the most prevalent form of identity credential on the Internet. The Hacker’s Dictionary defines a cookie as a handle, transaction ID, or other token of agreement between cooperating programs. The claim check you get from a dry-cleaning shop is a perfect example of a cookie; the only thing it’s useful for is making sure that you get your clothes back by relating two transactions that happen at different times.

On the Internet, cookies are exchanged between the browsers people use to access the Web and the servers the people visit. These cookies serve the same purpose as the claim check in the dry cleaning example: they tie transactions together that are otherwise difficult to connect.

To see how this works, suppose I use my browser to visit a web site I’ve never been to before, let’s call it http://www.foo.com. The people who maintain http://www.foo.com configured the server to give a cookie to everyone who visits. So, on my first visit to the site, the server passes a cookie back to my browser. My browser dutifully stores the cookie in a file on my computer used especially for this purpose. The magic of cookies happens the next time I request a page from http://www.foo.com (which could happen in the same browsing session or days or even weeks later). When I tell my browser to retrieve a page from http://www.foo.com, my browser sends back the cookie it received on the last visit.

So, let’s review what has happened:

That’s really the long and short of cookies. There are some more details, but all cookies obey these rules.

Cookies were added to servers and browsers to identify the same user over multiple sessions. Because HTTP is a stateless protocol, every request looks like a different session. This ability to link together time-separated transactions is what allows a web site to run a shopping cart, remember who you are, fill in forms for you, or remember your password between visits. Just as you wouldn’t return to a dry cleaner who couldn’t match up their customers with their clothes, web sites without the ability to link transactions across time are pretty boring.

Cookies aren’t typically thought of as an authentication device, but they are a credential that is used to lay claim to a particular identity. Cookies have a single authentication factor: “something I have.” Cookies are a weak form of authentication, because there’s no way to ensure that the same entity is using the cookie from visit to visit. The browser might be on a shared computer. I can even move cookies from one browser to another, if I’m clever, and let multiple people use the same cookie. Even with these problems, cookie-based identities are useful in a variety of circumstances. Chances are, you’ve got hundreds of cookie-based identities that you’re largely unaware of.

If you’re like me, you have dozens of ID/password pairs on various computer systems around the Internet. By typing in an ID, we lay claim to an identity, and the password is used to authenticate that we are allowed to do so. The system uses the identity represented by the ID to associate attributes with the holder of the ID.

Strictly speaking, ID and password systems are a two-factor authentication system with the ID representing something I have and the password being something I know. The problem, of course, is that an ID is usually public and is easily duplicated. As a result, most ID and password systems are nearly as weak as a one-factor system.

Challenge-response systems are related to password systems. In a challenge-response system, the server generates a random string of characters, and the user is required to manipulate the string according to some predefined, and secret, algorithm and send it back to the server. The algorithm may include the use of a secret key. Usually, a computing device of some sort performs the manipulation so that the algorithm can be made more complicated and thus more difficult to guess.

To see how this works, consider a simple problem. Suppose Alice and Bob agree to meet at the zoo to exchange a package. Alice and Bob do not know each other by sight and agree to verify their identities by way of a spoken password. We’ve seen this played out in spy movies. The two parties approach each other and one says something and the other responds with a predetermined response. This is essentially no different than how cookies work.

In a challenge-response system, Alice could give Bob a number, say, 5634. Bob has been told that he’s to add 3133 to the number Alice gives him and repeat it back. He responds with 8767. Alice performs the same calculation and gets the same answer and knows that Bob is the party she’s to meet. She could distinguish between multiple parties by the algorithm they use. Another party might have been told to reverse the number and add 3, for example.

Challenge-response systems have an advantage over ID/password systems, because the algorithm can be made sufficiently complex so that it is nearly impossible to guess. The disadvantages are that the algorithm must be coded on a special-purpose device or on the user’s computer and is subject to loss or theft.

A variation on the challenge-response system gives the user a special-purpose computing device called a token, which calculates a series of pseudorandom numbers. The token and the server that is doing the authentication both run carefully synchronized clocks. The token shows a new pseudorandom number periodically (say, every 60 seconds).

This number can be used in several ways. As a challenge-response system, the server could issue a challenge and the user could use the pseudorandom number to manipulate the challenge phrase in some way. This is more secure than having a predetermined algorithm.

In a second scenario, the user enters an ID, the number from the token, and a password in response to the challenge. The server uses the ID to retrieve the correct number and password and verify that they are correct. In this system, the server doesn’t issue a challenge, but both the server and the token use a carefully synchronized, complex algorithm to calculate a shared secret.

The pseudorandom number token creates a two-factor authentication system where the user uses something that he has (the token) and something he knows (the algorithm or the password) to log in. An attacker would have to have both pieces to break into the system.

Challenge-response systems can be combined with ID and password systems to avoid transmitting passwords across the network. In this scheme, both the client and the server know the password. The server generates a challenge phrase and sends it to the user. The user creates a message digest for the challenge phrase using the password and sends the result back to the server. The server compares the response with the message digest it calculates for the phrase with the user’s password. If they match, the server knows that the client possesses the password without ever having to send it across the network. Care must be taken to ensure that the message digest algorithm and the way it’s combined with the password are cryptographically sound or an attacker may be able to deduce the password from the network traffic.

We discussed digital certificates in detail in Chapter 6. Because certificates aggregate identity information and a public key that has been signed by a third party, digital certificates can easily be turned to the task of authentication.

The simplest way of using a digital certificate for authentication is in a challenge-response system. In this use, the digital-signing algorithm is substituted for the secret algorithm. The server generates a random string and sends it to the user. The subject digitally signs the random string and sends it back to the server. The server can verify that the random string is the same one that it generated and was in fact signed by the owner of the certificate. Once verified, the identifying information in the certificate can be assumed to belong to the subject.

Besides their cryptographic security advantages, digital certificates have other advantages over other authentication mechanisms. Multiple digital certificates can be associated with a single account so that a user does not need to hold multiple accounts to store different sets of attributes. Because the attributes can be stored in the certificate, the correct attributes are selected based on the certificate that the user presents. Furthermore, as we’ve seen, the certificate data structure can be extended so that it carries information specific to its use.

Even with their inherent security and other advantages, however, digital certificates have not had much success in authentication systems. Microsoft and others have invested millions of dollars building systems for creating, administering, and using client-side certificates for authentication. The primary problem is that digital certificates are quite a bit more complicated for users to manage. The concepts surrounding digital certificates are considerably more difficult to understand than those of simpler systems like ID and password systems.

A secondary problem is that commercially issued digital certificates cost money. They must be renewed regularly, and users frequently forget their access codes or lose the certificate entirely, leading to costly refreshes. This ongoing expense can deter organizations from adopting digital certificates as their primary authentication mechanism.

The final straw is that, except in certain circumstances, digital certificates don’t provide a significant increase in the security of the authentication system. Digital certificates are usually stored on the user’s machine and protected by a password. That password is subject to all the disadvantages of passwords that we saw earlier. Impersonators with access to the user’s machine may be able to guess or crack the password being used to protect the digital certificate as easily as they can any other password.

All this doesn’t mean that digital certificates have no place in an authentication strategy, but you should understand why you’re using them and compare the return with the additional complexity and expense. Certificate-based authentication has found the most success in special-purpose applications where security is of particular concern. Even there, certificates are often misused. For example, we’ve seen that ignoring certificate-revocation lists is a common mistake.

Biometrics is the use of some physiological or behavioral trait to uniquely recognize a person. Physiological traits can include face characteristics, fingerprints, hand geometry, iris characteristics, or retinal maps. Behavioral traits are those that are learned or acquired like handwriting and signature characteristics or voiceprints. Biometric devices present the opportunity to build authentication systems that incorporate something you are as an authentication factor.

Biometric identification has long been the stuff of science fiction, but there is growing interest, primarily among government entities, in using biometrics to strengthen airport security, protect borders, and in other military and homeland security applications. You can even buy a PDA with a built-in fingerprint sensor.

As we’ve seen, most state-issued driver’s licenses contain a biometric identification device called a picture. When the driver’s license is presented as a credential, the integrated picture is used by the sophisticated face recognition technology we all carry around in our heads to ensure the credentials are being presented by the person pictured on the license. Similarly, when a biometric device is used to authenticate identity credentials, the user enters an ID or other identifying token and then, rather than entering a password, the user might touch a fingerprint recognition device or speak into a microphone.

Biometrics devices have an advantage over other authentication systems, because they are tied to a person uniquely. This property allows biometrics to be used for identification, not just authentication of credentials. To understand the difference, consider the problem of ensuring that a person receives a government entitlement like food stamps only once. Crooks can fraudulently obtain credentials and apply for entitlements under different names. Biometrics determine whether the person, rather than a set of credentials, is known to the system and whether that person has previously been enrolled. This is sometimes called negative identification, because its goal is to prove that someone isn’t on a list.

This advantage also represents the most significant disadvantage of biometrics. While unlikely, biometric characteristics might be duplicated or cheated. Once a biometric identification characteristic is compromised, there is little recourse. You can’t easily issue new irises or fingerprints to replace the compromised feature.

The other side of this problem is that there are individuals who don’t fit into the standard patterns. For example, hand geometry devices cannot successfully identify the hand geometry of individuals with polydactylism (one or more extra fingers), yet this occurs in 0.2% of the general population. This can pose a difficult choice when system security depends on such a device. To see why, imagine a scenario in which a data center has installed hand geometry scanners at each of its doors and relies on them for perimeter security. If a polydactyl individual is hired, the company would be required to accommodate this disability, at least in the U.S. Most reasonable accommodations would create a special-purpose breach in the security wall or reduce the automation level of the authentication system.

Smart cards are credit card-sized devices that contain an embedded electronic chip and a simple interface for accessing the memory or processor on the chip. Most cards have a small set of contacts on the front, and when the card is inserted into a card reader, those contacts provide power and data interfaces to the electronics on the card.

Smart cards are something you have and can be used in authentication systems in a variety of scenarios. The most obvious scenario is to use the memory on the card to store a digital certificate. The advantage to storing the digital certificate on a smart card is its portability. On a card that contains both memory and a processor, the onboard processor can be used for encryption and decryption tasks and for verifying authorized access to the private key. Using the onboard processor in this way reduces the need to transport the keys off the card, decreasing the chance that they’ll be compromised.

Smart cards can also be used to implement a challenge-response system. In this use, the set of algorithms used to manipulate the challenge phrase are encoded in the card. The card can be placed in a reader attached to the user’s computer or the card can be inserted into a low-cost special-purpose device that allows the user to enter the challenge phrase and displays the result of the manipulation.

Some smart cards contain a built-in thumb-print reader, creating a portable biometric device. The biometric factor is used to ensure that the owner of the smart card is the one presenting or using it. This kind of system could potentially combine cryptographically strong digital certificates in a package that offers three-factor authentication: something you are, your thumb-print; something you have, the card; and something you know, a password.

Perhaps the most widespread use of smart cards for identity is in the cell phone industry. GSM phones rely on a Subscriber Information Module (SIM) that provides an individual identity for each mobile user account. Removing the SIM from one phone and placing it in another transfers the user’s identity, including her network information, phone number, and, in most cases, address and contact information to the new phone. The SIM is just a smart card that allows the electrical contacts and processor to be punched out of the larger card and inserted into a small receptacle in the phone.

Smart cards have been available for many years, but have, thus far, failed to be adopted for widespread use in identity management. The primary drawback is the additional hardware needed to read the cards. For example, deploying a smart card-based identity management system in a large organization would require outfitting each desktop workstation with a smart card reader. Beyond the capital costs, the readers have to be maintained and managed.

Practicality is probably the most important feature that any authentication system can have. From the user’s standpoint, the authentication system should be easy to use and non-intrusive. No one likes an authentication system that asserts itself too frequently or asks for authentication when none is needed. Users also dislike multiple authentication systems for multiple resources when the user sees those resources as related. For example, from the users’ standpoint, email lives on the desktop computer, and once they’ve signed on to their computers, they don’t want to reauthenticate to read their email.

From the enterprise’s viewpoint, the authentication system should scale well, provide the appropriate level of protection, and be cost effective. Enterprises want easy-to-use systems as well, due to high support costs. Enterprises need to manage authentication by large, diverse groups. For example, customers, employees, and the employees of partners and suppliers all need access to resources that the enterprise controls. Each of these groups has unique needs, and the authentication system should adapt to those needs.

Systems that require new software to be installed on user computers or, worse yet, require new hardware (like biometric devices and smart card readers) are difficult to deploy and maintain. This adds to the ongoing operating cost of the solution.

Different applications require different levels of security. As we’ve seen, there are many different ways to authenticate credentials with varying combinations of authentication factors. The security of an authentication scheme is directly dependent on the number and type of authentication factors used. So is the cost. Good design will match the level of authentication to security requirements.

The overall evaluation of authentication strength is subjective. Expert knowledge is needed to evaluate the weaknesses of complex systems like cryptographic key systems. Comparing two systems and judging their relative strength is easier, provided they are not too similar. Deciding that a system built on digital certificates is more secure than one based on user IDs and passwords is easy. Deciding the relative strength of two different ID and password systems that differ only in policy details, such as password length and type, is nearly impossible.

Mobility is an important factor in modern IT systems and users require access at multiple locations, some of which are not predictable or under the control of the enterprise. Locationally, transparent authentication systems can authenticate user credentials regardless of where the user may be located.

Protocol-insensitive authentication systems can be used on top of multiple transport and application protocols and to access resources. Servers for HTTP, FTP, POP, SMTP, and other protocols all incorporate some kind of authentication system. Take care to ensure that the authentication system and various servers interoperate. New tools offer the developer easy access to authentication, but it may not be as easy to create systems that interoperate. Web services, J2EE, .NET, and other regimes offer authentication methodologies, but they are not necessarily compatible without effort by the enterprise.

The extent to which user data is kept private depends on the enterprise and the resources being protected. For example, in the U.S. at least, employee access to company resources, such as desktop computers and email, can be logged and tracked to whatever extent the employer feels is appropriate. On the other hand, an authentication mechanism on a system that allows patients at a medical center to view their treatment records must provide more privacy protection because of laws and regulations such as HIPPA.

Reliability is crucial, because the authentication system can be the foundation for access to mission-critical resources. Reliability requires appropriate redundancy, operational excellence, configuration management, close monitoring, and proactive capacity planning. When the authentication system is used by other organizations, they may require a service-level agreement that stipulates specific uptimes and penalties for failing to meet them.

Accountability requires that the system be auditable. Transactions logs make it possible to review and track user actions and are the heart of an auditable system.

Logs can be made at various levels. Aggregate logs do not track individual transactions, but rather they aggregate data such as totals, averages, and trends. These can be useful for capacity planning and understanding the overall operation of the system.

Detailed logs track individual actions and are required for some problems like security breeches. Authentication system logs provide an important resource for dealing with system intrusions, but may be subject to legal and other restrictions and policies.

If not properly protected, detailed logs can raise privacy and security concerns, even when the data they contain seems relatively innocuous. Traffic analysis is the art of deducing information from the patterns in messages. For example, if I know that the CFO always accesses certain company investor resources before a big deal is announced and I have access to the authentication logs for those resources, I may be able to use that information to trade ahead of the market.

Manageability means that the operator of the authentication system can easily add, update, or delete users. The system should allow new classes of users and provide for different configurations among groups. Operators will add, renew, and delete certificates; maintain licenses; and update the system as new releases of the software become available. The interfaces to the authentication system should be well documented and easy to integrate into new and legacy systems. We’ll talk about directories in Chapter 9; they can provide a repository for much of the information that would be used in an authentication system. In many cases, the manageability of the authentication system will be a factor of the user interface and features of the directory systems employed by the enterprise.

Today’s enterprise has resources that must be accessed by the employees of its partners and suppliers as well as by their customers or constituents. An authentication system that supports federation will allow those entities to be managed by their respective organizations. This requires confidence in the partner organization and significant planning.

One of the crucial factors will be agreeing with partner policies about resource access and how the partner is verifying identity when it issues credentials. If the partner’s authentication system is going to be trusted to make authentication assertions, then the policies surrounding that system and the relative strength of its authentication system will need to be understood.

We’ll discuss federation in more detail in Chapter 12.