CHAPTER 28

IDENTIFICATION AND AUTHENTICATION

Ravi Sandhu, Jennifer Hadley, Steven Lovaas, and Nicholas Takacs

28.1 INTRODUCTION

28.2 FOUR PRINCIPLES OF AUTHENTICATION

28.2.1 What Only You Know

28.2.2 What Only You Have

28.2.3 What Only You Are

28.2.4 What Only You Do

28.3 PASSWORD-BASED AUTHENTICATION

28.3.1 Access to User Passwords by System Administrators

28.3.2 Risk of Undetected Theft

28.3.3 Risk of Undetected Sharing

28.3.4 Risk of Weakest Link

28.3.5 Risk of Online Guessing

28.3.6 Risk of Off-Line Dictionary Attacks

28.3.7 Risk of Password Replay

28.3.8 Risk of Server Spoofing

28.3.9 Risk of Password Reuse

28.3.10 Authentication Using Recognition of Symbols

28.4 TOKEN-BASED AUTHENTICATION

28.4.1 One-Time Password Generators

28.4.2 Smart Cards and Dongles

28.4.3 Soft Tokens

28.5 BIOMETRIC AUTHENTICATION

28.6 CROSS-DOMAIN AUTHENTICATION

28.7 RELATIVE COSTS OF AUTHENTICATION TECHNOLOGIES

28.8 CONCLUDING REMARKS

28.9 SUMMARY

28.10 FURTHER READING

28.11 NOTES

28.1 INTRODUCTION.

Authorization is the allocation of permissions for specific types of access to restricted information. In the real world, authorization is conferred on real human beings; in contrast, information technology normally confers authorization on user identifiers (IDs). Computer systems need to link specific IDs to particular authorized users of those IDs. Even inanimate components, such as network interface cards, firewalls, and printers, need IDs. Identification is the process of ascribing an ID to a human being or to another computer or network component. Authentication is the process of binding an ID to a specific entity. For example, authentication of a user's identity generally involves narrowing the range of possible entities claiming to have authorized use of a specific ID down to a single person.

The focus of this chapter is on person-to-computer authentication. In practice, we also need computer-to-person authentication to prevent spoofing of services on a network. This type of authentication is increasingly important, especially on open networks such as the Internet, where users may be misled about the identity of the Web sites they visit. For example, some criminals send unsolicited e-mail messages in Hypertext Markup Language (HTML) to victims; the messages include links that are labeled to suggest an inoffensive or well-respected Web site, but the underlying HTML actually links to a fraudulent site designed to trick people into revealing personal information, such as credit card numbers or details to support theft of identity. More generally, computer-to-computer mutual authentication, typically in both directions, is essential to safeguard critical transactions such as those of interbank transfers and business-to-business electronic commerce.

In the early decades of computer usage, most computers authenticated users who accessed mainframes from within a single enterprise. User IDs therefore could be assigned in a centralized and controlled manner. Even so, identifiers have never necessarily been unique, for there is no obligatory one-to-one relationship between a user ID and a human being's real-world identity. For example, several people could share an account such as inventory_clerk without interference from the computer; at most, the operating system might be configured to prevent simultaneous sharing of an ID by limiting to one the number of sessions initiated with a specific ID.

Conversely, a single user often has many user IDs. For example, there may be unique identifiers for each of dozens of Web sites for music clubs, book clubs, enterprise e-mail, and so on. Even on the same computer, a given user might have several accounts defined for different purposes; jane_doe and jdoe might be identifiers for two different application packages on a system. These multiple identifiers cause problems for administrators if they do not know that the same user is associated with the different IDs; they also cause practical problems for users who have to use different authentication methods for a range of IDs. One of the critical goals of today's identification and authentication (I&A) research and development is to develop reliable and economical methods for single signon, whereby users would not have to reidentify and reauthenticate themselves when accessing different computer systems linked into an Internet. For details of I&A in facilities security, see Chapter 23 in this Handbook.

28.2 FOUR PRINCIPLES OF AUTHENTICATION.

Authentication of a claimed identity can be established in four ways:

1. What only you know (passwords and passphrases)
2. What only you have (tokens: physical keys, smart cards)
3. What only you are (static biometrics: fingerprint, face, retina, and iris recognition)
4. What only you do (dynamic biometrics: voice, handwriting, and typing recognition)

In each approach, the assumption is that no one else but the authorized user of an identifier has access to the password or token and that the probability of simulating static or biometric data is acceptably low.

These methods can be combined; for example, passwords often are combined with tokens or biometrics to provide stronger authentication than is possible with either one alone. A familiar example of this two-factor authentication occurs with automatic teller machine (ATM) cards. Possession of the card (the token) and knowledge of the personal identification number (the PIN, corresponding to a password) are required to access a user's bank account.

This chapter introduces each of these four authentication methods and provides additional details for each. For discussions of methods of bypassing and subverting identification and authentication techniques, see Chapter 15 in this Handbook.

28.2.1What Only You Know.

Password- or passphrase-based authentication is so widely used that any person who has had any contact with computers and networks probably has had several passwords. Although password technology often is poorly administered and insecure (and frustrating) for users and administrators, passwords can be deployed much more securely and conveniently than they usually are. Many security professionals have felt and hoped for years that passwords would eventually be phased out, to be replaced by tokens or biometrics, but the consensus today is that passwords are not likely to disappear soon and that they will continue to be the dominant authentication technique for years to come.

Demonstrating knowledge of a password does not directly authenticate a human being. It simply authenticates knowledge of the password. Unauthorized knowledge of, or guessing at, a password can lead to impersonation of one user by another; this is called spoofing. The theft of a password can be difficult to detect since it is not a tangible asset. Passwords are also very easy to share. It is common for senior executives to give their passwords to their assistants to facilitate their work, even though assigning proxy privileges would be as effective and more secure.

28.2.2 What Only You Have.

Authentication based on possession of a token is used where higher assurance of identity is desired than is possible by passwords alone. As with passwords, possession of a token does not directly authenticate a human being; rather it authenticates possession of the token and ability to use it. Sometimes a password or PIN is required to use the token, thus establishing two-factor authentication; the theory is that the requirement to have both elements decreases the likelihood of successful spoofing.

Tokens can take on a variety of forms. The oldest token is the physical key for a physical lock, but these are not often used for securing computer systems. Soft tokens are carried on transportable media or even accessed over a network from a server. Soft tokens contain only data; they typically require a password to access the contents. Modern tokens are usually implemented in self-contained hardware with computing capability. Examples include:

• Credit card–size devices with a liquid crystal display (LCD) that display pseudorandom numbers or other codes.
• LCD devices in the shape of a key fob using the same algorithms as the credit card–shape devices.
• Hardware devices called dongles that plug into input-output ports on computers. Examples include dongles for serial ports, parallel ports, Universal Serial Bus (USB) ports, and PC-card interfaces.

All tokens used for computer authentication require software to process information residing in or produced by them. The most significant distinction is whether the tokens require electronic contact with the authentication system. Contactless tokens are easier to deploy because they do not require specialized readers. For example, the credit card and key fob pseudorandom number generators simply require the user to enter the visible code in response to a prompt from the authentication software. Contactless tokens are more limited in function than contact tokens. For instance, a contact token can be used to create digital signatures whereas a contactless token cannot do so practically.

In cyberspace, a token does not authenticate by means of physical characteristics. Rather the token has some secret, either exclusive to itself or possibly shared with a server on the network. Authentication of the token is really authentication of knowledge of the secret stored on the token. As such, authentication based on possession of a token is tantamount to authentication based on what the token knows. However, this secret can be longer and more random than a secret that a user has to retain in human memory, such as a password. Unfortunately, building cost-effective and secure tokens from which the secret cannot be extracted by tampering or by brute-force guesswork has proven much more difficult than initially anticipated. In the early 1990s, many security professionals believed that tokens would replace passwords; in fact, however, although tokens continue to be an attractive authentication technology, they probably will not become pervasive soon because of the consistent (but highly debatable) belief that passwords are less expensive to implement and manage than other methods of authentication (see Section 28.7).

28.2.3 What Only You Are.

Biometrics takes authentication directly to the human being. This topic is covered more extensively in Chapter 29 in this Handbook, but the basics can be mentioned here.

As humans, we recognize each other by a number of characteristics. Biometric authentication seeks to achieve a similar result in cyberspace. A static biometric is a characteristic of a person such as fingerprint, hand geometry, or iris pattern; more dramatically, it could be the DNA of an individual. The likelihood of two individuals having identical fingerprints, iris patterns, or DNA is minuscule (with exceptions for genetically identical siblings). Biometrics requires specialized and expensive readers to capture the biometric data, making widespread deployment difficult.

Biometrics also suffers from the problems of replay and tampering. Thus, the bio-metric reader must itself be trusted and tamper-proof; this reduces the likelihood of an attacker capturing the data input and replaying it at a later time, or creating false bio-metric profiles to trick the system into accepting an imposter. Moreover, the biometric data themselves must be captured in proximity to the user to reduce the likelihood of substitution, such as the case in stolen blood used to fool a DNA-based biometric system. If the data are transmitted to a distant server for authentication, the transmission requires a secure protocol, with extensive provisions for time-stamping and rapid expiration of the data.

28.2.4 What Only You Do.

Dynamic biometrics captures a dynamic process rather than a static characteristic of a person. A well-known example is that of signature dynamics. Signature dynamics involves recording the speed and acceleration of a person's hand as a signature is written on a special tablet. Rather than merely the shape of the signature, it is the dynamic characteristics of motion while writing the signature that authenticates the person—motions that are extremely hard to simulate. Another possibility is to recognize characteristics of a person's voice as he or she is asked to read aloud some specified text. Keystroke dynamics of a person's typing behavior is another alternative.

As in all other forms of authentication, dynamic biometrics depends on exclusion of capture and playback attacks, in which, for example, a recording of someone's voice might be used to fool a voice-recognition system. Similarly, a signature-dynamics system might be fooled by playback of the data recorded from an authentic signature. Encryption techniques help to make such attacks more difficult.

Security experts agree that biometrics offer a stronger guarantee of authentication, but deployment on a large scale remains to be demonstrated. Whether this technology becomes pervasive ultimately may be determined by its social and political acceptability as much as by improved technology.

28.3 PASSWORD-BASED AUTHENTICATION.

Passwords are the pervasive technology for authentication in cyberspace today. At a conservative estimate, there are close to a billion password-based authentications per day. Examples include the vast number of Internet users and the number of passwords each one uses every day. However, the current deployment of password technology needs to be improved in many ways. Today users must remember too many identities and corresponding passwords. Also, the deployed technology is more fragile than it needs to be; for example, many users choose passwords that can be guessed easily. Passwords are never going to be as secure as the strongest biometric systems, so one would not use them as the sole basis for, say, launching nuclear missiles. However, their use can be made strong enough for many less critical transactions.

The next sections review the major risks of password use and their mitigation by technical, social, and procedural means.

28.3.1 Access to User Passwords by System Administrators.

One of the most dangerous practices in use today is the storage of unencrypted user passwords accessible to system administrators. In some sites, new users receive passwords that are assigned and written down by system administrators. If these passwords are used only once, for the initial logon, the user can be forced to choose or create a truly secret password that no one else knows. However, in many such sites, administrators keep control of a paper or electronic record, usually for quick access when users forget their own passwords. Such access completely destroys an important element of I&A: nonrepudiation. If someone else has access to a password, then authorized users can reasonably repudiate transactions by claiming that their identities were spoofed. It is difficult to counter such repudiation, especially in a court of law considering an accusation of malfeasance by the authorized user of that password. In general, passwords that will be used repeatedly should not be written down, and they should not be accessible to system administrators. Critical passwords can be written down, stored in tamper-proof containers, and locked away where at least two signatures will be required for retrieval in case of emergency.

28.3.2 Risk of Undetected Theft.

Perhaps the biggest intrinsic risk with passwords is that they can be stolen without knowledge of the user. Observation of someone typing in a password is sufficient to leak it. This can happen surreptitiously without the victim's explicit knowledge. A related risk is disclosure of a password to an attacker who persuades the legitimate user to reveal it by posing as a systems administrator who needs the password to do something beneficial for the user. Loss of a physical token eventually may be discovered, since it is missing, although the possibility of cloning these devices remains. Loss of a password, however, can be discovered only by detecting its misuse or by finding it in the possession of an unauthorized user (e.g., in a list of passwords cracked by using a dictionary-based password-cracking program, as described in Section 28.3.6).

There are several mitigations of this risk. First, user education and awareness are critically important. People need to treat important secrets with the care they deserve. In an unsafe environment, a password should be typed in discreetly. Efforts to be discreet should be positively reinforced while negligence in exposing passwords during entry should be considered akin to bad social behavior.

User education and awareness, although extremely important, can never be the whole solution. People will inevitably slip up and make mistakes. Some of us are more negligent than others. Others will be observed surreptitiously. In some cases passwords will be revealed to computers with Trojan horses (see Chapter 16 in this Handbook) that capture them. Technologists must pursue technical and human solutions to mitigate these risks.

Since some losses of control over passwords are inevitable, it logically follows that password-based authentication should be used only in situations where misuse detection is not only feasible but actually convenient to do in real time. To make this possible, the system architecture should centralize the information needed for misuse detection in one place. If the required information is dispersed across many servers, it will be difficult to coordinate the different audit trails. Traditionally, users of password systems have not considered the need for misuse detection. However, modern security is firmly based on a mix of prevention and detection techniques. Security professionals should apply similar thinking to authentication systems. Ease of misuse detection should be an important criterion in the design of any authentication system. For password-based systems, misuse detection capability should be considered an essential requirement. (For information on intrusion-detection systems, see Chapter 27 of this Handbook.)

What else can system designers do to mitigate this risk? It should be made easy for users to change their passwords themselves. Having a system administrator change a password that will be used more than once is illogical.

If a user feels that a password may have been compromised, changing it should be a simple matter. In particular, the system should never prevent a user's attempt to change a password. Some deployed systems will deny change of a password if the password was changed recently, say in the past 24 hours. Although there are reasons for this kind of restriction, it may create a bigger risk than the one it purports to prevent.

Users should be encouraged to change their passwords fairly often; a typical allowable lifetime for a password is between 30 and 90 days. Without occasional changes, a compromised password could be held until the malicious attacker finds opportunity to use it. Frequent changes to passwords reduce the window of opportunity for such attackers.

28.3.3 Risk of Undetected Sharing.

Another major risk of passwords is the ease with which they can be shared. There are many examples of sharing between executives and their secretaries, between physicians and office staff or nurses, between professors and their secretaries or students, and among coworkers in any activity. User education and strict policies against password and account sharing are obvious first steps to deter this possibility. Strict policies can be effective within an organization, but their deterrent effect may not carry over to large consumer populations. Misuse detection also can be employed to enforce a strict policy.

The root cause of password sharing within an organization is the lack of effective delegation mechanisms whereby selected privileges of one user can be delegated to another. Better authorization mechanisms could eliminate much of the perceived need for password sharing. It should be possible for secretaries to read their boss's e-mail under their own identity and password. In fact, the bosses should be able to segregate the e-mail that the secretaries can read while denying access to more sensitive e-mail. Moreover, reading the boss's e-mail should be possible without allowing the secretary to send e-mail under the boss's identity; a proxy privilege could allow secretaries to answer their boss's e-mail while signing the replies with their own names. In the nonelectronic world, secretaries routinely answer mail for other people without impersonating them, and this should be the practice with computers as well.

Sharing of passwords among consumers is likely to occur when the cost to consumers is minimal. Although consumers are unlikely to share passwords for an online bank or brokerage account with others, they may be willing to share passwords for an online subscription service, possibly with many friends. A dishonest consumer may even make a business of reselling the service. One way to deter such piracy would be to tie exposure of the password to exposure of a sensitive secret of the consumer, such as a credit card number. Few people, criminal or not, would hand over a password that includes their own credit card number.

Another approach that reduces account sharing is one-time passwords that are generated by inexpensive tokens that have recently been distributed to consumers by Web merchants and banks (e.g., Citibank starting in May 2006) as a method for authenticating identity.¹ These tokens generate random passwords that change every minute or so and that can be traced to the specific unit that creates them—and that unit can be tied precisely to the original recipient. Not only does such a system make password sharing virtually impossible, but a shared password can be traced directly to the violator of the terms of use and result in legal action and fines. For more on one-time passwords, see Section 28.4.1.

28.3.4 Risk of Weakest Link.

One of the frustrations of passwords is that users have to remember too many. Thus, users tend to repeat selection of the same password at multiple sites. This is a very insidious risk. Exposure of a user password at a poorly maintained site can lead to penetration of the user's account at numerous other sites. It is not easy to deploy technical measures to protect directly against this risk. A particular site can force a user to pick a complex password or can even choose the password for the user. However, it cannot prevent use of the same password elsewhere. This is one area where user education, awareness, and self-interest are paramount. Malicious attackers can set up rogue Web sites easily, to entice users to register for attractive services, whereupon the user's password for other sites may be revealed.

A technical solution to mitigate this problem is to avoid the requirement that a user has to register at multiple sites with user IDs and passwords. Instead, the user should register at a few trusted sites, but the user ID should be usable at multiple sites by secured sharing of assurances that the user has in fact been identified and authenticated sufficiently for business to continue. This is essentially what public key infrastructure (PKI) seeks to do. Once a user has identified him- or herself to a provider of such electronic credentials (client certificates), the certificate becomes a method for authentication, For example, some banks provide a service that allows a user to create a unique number that can substitute for their credit card number in a particular transaction. The user authenticates to the bank site, obtains a unique certificate that substitutes for the credit card number, and gives it to the merchant. The merchant can verify that it generates a valid transaction authorization but never knows the original credit card number. With authentication based on client certificates, it is not necessary to expose a user's password to multiple sites. An effective marriage of passwords and PKI would reduce the exposure to the weakest link. For more details of PKI, see Chapter 37 in this Handbook.

A similar approach stores sensitive information in one place and then directs businesses to that place for payment information. For example, today a number of systems (e.g., PayPal) allow a user to register credit card information once, with a trusted service, and then pay online retailers (e-tailers) via that service.

28.3.5 Risk of Online Guessing.

Authentication systems are susceptible to guessing attacks. In online guessing, an attacker tries to authenticate using a valid user ID and a guessed password. If the password has been poorly selected, the attacker may get lucky. The attacker also may be able to exploit personal knowledge of the victim to select likely passwords. This approach exploits the documented tendency of naive users to select passwords from lists of obvious words, family, friends, pets, sports, commercial brands, and other easily obtained information. For example, studies of password files consistently show that the most frequently selected password in the world is “password”; the second most frequent is the user ID itself or the user ID backward. An account with the same password as the user ID is often called a Joe account, as in User ID: joe; Password: joe.

Another kind of password vulnerable to guessing is a password assigned by default; for example, many software installations create accounts with the same password on all systems. Documentation usually warns users to change those canonical passwords, but many people ignore the warning. Canonical passwords are particularly dangerous when they grant access to powerful accounts, such as root accounts or to support functions.

The first line of defense against online attacks is to enforce password complexity rules, in addition to user education and awareness. Many systems today require a minimum of eight-character passwords with a mix of upper- and lower-case letters, numerals, and possibly special characters. Nonetheless, online guessing attacks are still possible, and system logging (see Chapter 53) or application logging (see Chapter 52) can be helpful in identifying successful impersonation. For example, log files may show that a particular user has never logged on to a particular account outside working hours, yet someone has logged on as that user in the middle of the night.

Some systems react to online attacks by a simple rule that locks the account after a certain number of failed attempts. This rule may have been borrowed from a similar rule with ATM cards. The rule actually makes sense in the context of ATMs, with two-factor authentication based on possession of the card and knowledge of the PIN. However, in a password-only scheme, the “three strikes and out” rule can lead to denial of service to legitimate users. An attacker can easily lock up many accounts by entering three wrong passwords repeatedly. A more graceful rule would slow down the rate at which password guessing can be attempted, so that a legitimate user may be perceptibly slowed down in authentication but not denied. For example, locking an account for a couple of minutes after three bad passwords suffices to make brute-force guesswork impractical.

In addition, intrusion-detection systems can be configured to alert system administrators immediately upon repeated entry of bad passwords. Human beings then can intervene to determine the cause of the bad passwords—user error or malfeasance.

28.3.6 Risk of Off-Line Dictionary Attacks.

The paramount technical attack on password-based authentication systems is the dictionary attack. Such attacks start with copying the password file for a target system and placing it on a computer under the attacker's control. The password file normally uses one-way encryption that allows the system to encrypt an entered password and compare it to the encrypted form of the legitimate password. If the two encrypted strings match, the entered password is presumably correct, and so the system authenticates the user ID.

The dictionary attack is described as off-line because the attacker obtains the necessary information to carry out the attack and then performs computations off-line to discover the password from this information. It is a guessing attack because the attacker tries different likely passwords from an extensive list of possible passwords (the dictionary). The list of likely passwords is called a dictionary because it includes words from one or more natural languages, such as English and Spanish; specialized versions used with password-cracking programs may sort words by frequency of use rather than alphabetically to speed up successful guesses.

The initial response to dictionary attacks was to stop users from selecting passwords that could be cracked via a dictionary attack. In essence, the system would try a dictionary attack; if it succeeded, it would prohibit the user from selecting this password. This is not a productive approach because attackers' dictionaries are often ahead of the system's dictionaries. The productive approach is to prevent the attacker from collecting the information necessary to carry out the dictionary attack.

Designers of password-based authentication systems were slow to recognize the risk of dictionary attacks. It has long been understood that passwords should not be stored on a server in cleartext because this becomes a single point of catastrophic failure. Time-sharing systems of the early 1970s stored passwords in a “hashed” form. Knowledge of the hashed form of a password did not reveal the actual password. Authentication of passwords was achieved by computing the hash from the presented password and comparing with the stored hash. The UNIX system actually made the hashed form of user passwords easily readable, since reversing the hash was correctly considered computationally infeasible. However, knowledge of the hashed form of a password is sufficient for dictionary attacks. The attacker guesses a password from a list, or dictionary, of likely passwords, computes its hash, and compares it with the stored hash. If they match, the attacker's guess is verified; otherwise the attacker tries another guess. Since the late 1980s, UNIX systems have stopped making the file of hashed passwords easy to read, so this vulnerability has been reduced.

UNIX also introduced the concept of a salt to make dictionary attacks more difficult. The user password and a random number called the salt are hashed together and stored on the server. The salt itself is also stored on the server. To authenticate a user, the presented password and the stored salt are hashed and compared with the stored hash value. Use of a salt means that a separate dictionary attack is required for every user, since each password guess must be hashed along with the salt. Otherwise, the same attack could be run simultaneously against multiple presented passwords.

28.3.7 Risk of Password Replay.

If a password is transmitted in cleartext from client to server, it is susceptible to being picked up on the network by an intruder. This is called password sniffing. Many systems require the password to be sent to the server in cleartext. Others require transmission of a hash of the password (usually without a salt). Transmitting the hash of a password is risky for two reasons:

1. The hash is sufficient for a dictionary attack unless a salt is used and kept secret.
2. The attacker does not even need to recover the password. Instead, the attacker can replay the hash of the password when needed.

Many existing systems are susceptible to sniffing of passwords on the network in cleartext or hashed form. Fortunately, technical solutions to this problem do exist.

One approach to the replay threat is to use the server's public key to encrypt any transmission of password-related information to the server: Thus, only the server can decrypt the information by using its private key. This is essentially what server-side SSH (Secure Shell) and server-side SSL (Secure Sockets Layer) do. The server-side mode of both SSL and SSH require the server to have a public key certificate. The client-side mode of these protocols requires that the client also have a public key certificate. This approach can be effective but has its own risks.

An alternate approach is to avoid transmitting the password but instead to employ a protocol that requires knowledge of the password to run successfully. One of the earliest and best-known systems to take this approach is Kerberos. In this system, a user's password is converted to a secret key on the client machine and also stored on the Kerberos server. When the user requests authentication, the Kerberos server sends the user's machine a secret session key encrypted using the shared secret key derived from the user's password. The ability to decrypt this message correctly demonstrates knowledge of the password without actually transmitting it, in cleartext, hashed, or encrypted form. Unfortunately, the Kerberos protocol is susceptible to dictionary attacks; any client machine can pretend to be any user and can obtain the necessary information required for a dictionary attack.

Kerberos also does not use a salt, so the same dictionary attack can be applied to multiple users at one time. Kerberos Version 5 provides for a preauthentication option, which makes it somewhat harder to gather the information for a dictionary attack. The data are no longer available by simply asking the Kerberos server for them; instead they must be sniffed on a network. Recent experiments have shown that dictionary attacks on Kerberos are very practical, so this is a serious vulnerability of a widely deployed password-based authentication system.

Since the early 1990s, many password-based authentication protocols have been published that do not suffer from the dictionary attacks to which Kerberos is so vulnerable. In particular, zero-knowledge password proofs are based on the idea that two parties (computers and people) can demonstrate that they know a secret password without revealing the password. These methods depend on the ability to establish that the two parties both independently selected the same number—but without knowing what the specific number is.² One popular conceptual model of this process is the zero-knowledge password proof, which runs as follows:

1. Two people want to test whether they share a secret number (in this thought experiment, a single digit between 1 and 10). In this example, the shared number is 3.
2. The two people have a deck of 10 blank cards.
3. The first person counts down to the third card and makes a mark on the right edge of that card.
4. The deck of cards is arranged so that the second person can mark the left edge of the cards but cannot see the right edge.
5. The second person also counts down to the third card (in this example) and marks the left edge.
6. The card deck is shuffled so that the sequence order is lost and then displayed to both parties.
7. If a single card has a mark on both the right edge and the left edge, then the two parties share the secret number, but neither had to reveal exactly which number it was.³

It will be interesting to see if this approach to authentication can be implemented on actual computers and if it is commercially used on a significant scale in the coming years.

28.3.8 Risk of Server Spoofing.

As mentioned earlier, one widely used approach to preventing password exposure in transit on a network is to send passwords from client to server encrypted using the server's public key. The server, which has the corresponding private key, can decrypt the password to recover it. Knowledge of the public key is not sufficient for a spoofer to determine the private key. Naive protocols for protecting the private key can be susceptible to replay attacks. However, there are two well-designed protocols in widespread use today.

Server-side SSL is the protocol that has been used by most Web surfers. In this protocol, the server's public key is used to secure transmission of the user's password from client to server. Like all public key–based schemes, the Achilles' heel of this protocol lies in authentic knowledge of the server's public key. The technology of public key certificates seeks to provide public keys with good assurance of the identity of the server to which they belong. A full discussion of issues with Public Key Infrastructure technology appears in Chapter 37, but it suffices to observe that there are pitfalls with the use of certificates for authentication of servers. A rogue server can collect a user's password by pretending to be something other than what it is. Relying on the look and feel of a Web page for server authentication is hardly sufficient, since it is easy to copy an entire Web page for use as a decoy and to establish confidence before capturing confidential information. An improvement on Web site authentication is to associate a specific image and identifying strings (e.g., a picture of a hippopotamus labeled “Archie's Favorite Critter”) with a user ID; the Web site authenticates itself to a specific user (e.g., Archie) by displaying that user's chosen image.⁴ Authenticity of the server's certificate can be spoofed in many ways that are hard for the user to detect, and manipulation of the trusted root certificates that are configured in the user's Web browser is possible. Moreover, while trust ultimately chains up to a root certificate, the owner of a single certificate below a trusted root is capable of considerable mischief. Serverside Secure Shell is a similar protocol, typically used to provide secure remote access to UNIX servers. Server-side SSL and server-side SSH share the same fundamental vulnerabilities: Both can be spoofed by certificate manipulation. The use of serverside SSL to protect transmission of passwords from client to server is prevalent on the Internet today, but it is important for customers of authentication products to understand the risks inherent in this approach.

In the client-side mode of these protocols, there is no need for a password to be transmitted from client to server, since client-to-server authentication is based on the client's use of its own private key to generate a digital signature. Hence client-side protocols are not vulnerable to password capture by server spoofing.

28.3.9 Risk of Password Reuse.

The need to change passwords with some reasonable frequency is well recognized, but what is reasonable frequency? And how draconian should the enforcement be? It seems that security administrators have pushed too far on these questions. Forcing users to change passwords every month, and enforcing such rules ruthlessly, actually could lead to less security rather than more because so many frustrated users write down and store their ever-changing passwords in nonsecure places. There is a real risk here, created by well-meaning security administrators who have made the problem worse than it inherently is.

Systems that choose a password for the user have their own set of problems and are generally too user-unfriendly to be viable in the Internet age. This discussion focuses on systems that allow users to select their own passwords.

How does exposure of a password increase with time? Even the strongest password-based system, with immunity to off-line dictionary attacks and password capture by server spoofing, faces increased exposure as time passes. Over a long period of time, a slow, ongoing, online guessing attack could be successful. Also, the likelihood of inadvertent disclosure by surreptitious observation, or exposure on a Trojan horse–infected computer, increases with time. Nevertheless, a good password, carefully chosen by the user to be safe from dictionary attacks and well memorized by the user, should not be changed casually. A change every six months may be appropriate for well-chosen, brute-force–resistant passwords.

Enforcing password changes is a complicated business, and one where the security community has not really done a good job. It is not difficult to keep track of the age of a password and to force a change when an appropriate time has passed. The difficulty is in forcing the new password to be independent of the old one. In fact, the likelihood is that the new password will be a slight variation of the old one. For example, appending the numeral designating a month to a fixed string enables users to have almost the same password, even if they are forced to change it every month. Some systems will keep a history of recently used passwords to prevent their reuse. A system that keeps a history of, say, five passwords can be fooled by rapidly changing the password six times. To prevent this, there are systems that will not allow a user to change password more than once a day. This has the unfortunate effect of actually increasing risk of password exposure, since a user who realizes that the current password may have been inadvertently exposed cannot change it, exactly when the need to do so is greatest.

28.3.10 Authentication Using Recognition of Symbols.

An interesting new approach to user authentication is recognition of particular faces from among a large selection of random photographs. Passfaces software works in this way:

A white paper explains how human beings are particularly good at recognizing faces; indeed, it seems that we have special circuits that have evolved for rapid and accurate perception of faces. According to the paper, advantages of “using Passfaces over passwords” are that Passfaces:

• Can't be written down or copied
• Can't be given to another person
• Can't be guessed
• Involve cognitive not memory skills
• Can be used as a single or part of a dual form of authentication

The power of the system is enhanced by setting parameters to interfere with misuse of the faces. For example:

28.4 TOKEN-BASED AUTHENTICATION.

Token-based authentication relies on something that the user possesses that no other user of the identifier is supposed to possess or be able to access. This authentication can be achieved in many ways, including:

• One-time password generators
• Smart cards and dongles
• Soft tokens

28.4.1 One-Time Password Generators.

A popular form of token, from vendors such as RSA Data Security Inc. and CryptoCard, displays a one-time password, typically a six- or eight-digit numeral, which changes each time an access button is pushed or when a given time has elapsed since the password was last used. The user authenticates by entering the user ID and current value displayed by the token.

The password is called one-time because it expires at the end of its allowable period for use. The token is typically contactless, in that it does not need electrical contact with the computer where the user is presenting authentication data. The user transfers the necessary information from the token via a keyboard or other input device. To make this a two-factor authentication, a fixed user password is also required in addition to the changing one-time password displayed by the token. These tokens are based on shared secret keys, so both the token and the server have a shared secret. The server and the token need to be initialized and then kept synchronized for this scheme to work. In the case of RSA's SecurID, if the time discrepancy between a specific token and the authenticating system exceeds a specified limit, the authenticating software adjusts a value in an internal table to compensate for the time slippage. Vendors such as CryptoCard have developed event-based authentication algorithms to solve the “slippage” problem. These tokens use a seed with the algorithm to generate a unique value for each button push or other activating action. After the next login, that value is now “known” to the authenticating system, and a new value must be provided. The token's value increments based on the seed, without requiring synchronization with the authenticating system.

Password generators must be protected against physical tampering. These devices typically include several measures to cause destruction of the electronic circuits if the outer case is opened; for example, in addition to epoxy-resin glue, tokens may include light-sensitive components that are destroyed immediately by exposure to light, rendering the unit unusable. Some password generators and smart cards cannot even be opened to replace batteries, so the entire card must be replaced on a predictable schedule. Tokens of this kind are available that are guaranteed to last one year, two years, or three years, without having the batteries wear out.

28.4.2 Smart Cards and Dongles.

Another form of token is a smart card. These cards can go into a PC card reader or can be read by a specialized reader. Dongles are smart cards that fit into input-output ports such as USB. A smart card has its own processing capability and typically stores a private key associated with the user. Often a password or PIN is required to access the card, thereby providing two-factor authentication capability. The smart card enables user authentication by signing some challenge presented to it with the user's private key. The signature is verified by means of the user's public key. A complete discussion of such smart cards involves consideration of public key cryptography, public key certificates or so-called digital certificates, and supporting infrastructure or PKI (see Chapter 37 in this Handbook). Suffice it to say that smart cards have long been considered essential for widespread use of public key technology but so far have not been widely deployed.

Hardware tokens offer the potential for stronger authentication than passwords but have seen only limited use due to their perceived costs and their infrastructure requirements. Whether they can be deployed in a scale of millions of users remains to be seen. Authentication by tokens is really authentication by something that the token knows. Since tokens can be programmed to remember and use secrets much more effectively than humans can, they offer the potential of strong cryptographic authentication, but tamper-proof tokens are not easy to produce. In recent years, attacks based on differential power analysis have proven effective in determining the secret keys and PINs stored on smart cards. These attacks require physical access to a card whose loss probably would be known, so, although they may not always be feasible, they certainly call into question the presumed tamper-proof nature of smart cards. As smart cards are more widely deployed, other ingenious attacks are likely to be pursued. Smart cards are more susceptible to secret extraction than tokens because their computations leak such information in the form of electromagnetic radiation.

In comparing tokens with passwords, one can argue that undetected theft is easier with passwords. The token is a physical object whose absence is noticeable. However, tokens create their own problems. Like password generators, they are vulnerable to physical damage and compromise. Smart cards typically are built from thin plastic with a chip embedded in them, making the entire unit susceptible to failure from damage. In addition, users typically may store cards with other credit cards in a wallet or pocket, either of which presents additional environmental hazards. However, for certain industries, the cost of replacing lost or damaged tokens may be worth the reduction in undetected sharing, since a token can be used by only one person at a time.

28.4.3 Soft Tokens.

The idea of soft tokens, or software tokens, has been proposed as a low-cost alternative to hardware tokens. Early soft tokens consisted of a user's private key encrypted with a password and stored on some transportable medium, such as a floppy disk. Such a scheme is extremely vulnerable to dictionary attacks because a guessed password can be verified easily (by testing a putative private key to see if it decrypts a message encrypted using the user's known public key). Moreover, the physical transport of floppy disks and the possible lack of floppy disk drives have led people to store these soft tokens on network servers so they are accessible as needed. Unfortunately, this location also makes them easily accessible to attackers. Protecting access to soft tokens on a network server by means of a password simply returns to the problems of password-based authentication.

It has been suggested that a user's public key could be kept secret and known only to trusted servers to avoid dictionary attacks on the encrypted private key. This approach comes at the severe cost of a closed PKI rather than an open PKI. Schemes for retrieving the private key by means of a secure password-based protocol have been published and are being implemented by some vendors. These schemes ultimately revert to password-based authentication as their foundation. Schemes based on splitting the private key into two parts have been developed. One part of the private key is computed from the password; the other part is stored on an online server, which functions as a network-based virtual smart card. Both parts of the private key are needed for user authentication but are never brought together in one place.

An alternative scheme would be to store the user's entire private key on an online server and make its use contingent on a secure password-based protocol. This approach allows the server to impersonate any user at will and may not be suitable in all environments. However, in all cases, the security of the token relies on the integrity of the computer that uses it. Newer implementations of soft tokens rely on asymmetric cryptography to eliminate the security concerns with storing private keys in a file or other transportable location. The soft token can generate its own key pair and exchange public keys with the authentication server. Although this increases the security of the soft tokens, the concept is inherently weak and prone to attack.

The U.S. federal government established a standard for the identity cards it has mandated for all federal employees and contractors. The original Homeland Security Presidential Directive 12 (HSPD 12), dated August 27, 2004, was entitled “Policy for a Common Identification Standard for Federal Employees and Contractors.” It defined these requirements for

28.5 BIOMETRIC AUTHENTICATION.

Biometric authentication looks like an excellent solution to the problem of authentication in cyberspace. However, there are several challenges in implementing biometrics, including drawbacks in accuracy (false positive and false negative results), loss of biometric identifiers, security of templates, and privacy concerns. For a full treatment of biometric authentication, refer to Chapter 29 in this Handbook.

28.6 CROSS-DOMAIN AUTHENTICATION.

As more systems and processes become Internet enabled, people come to expect a seamless experience between organizations and applications across the Internet. Furthermore, the ever-increasing risk of identity theft has made individuals and organizations more careful about sending too much identity information across an untrusted network. Over the past several years, efforts have increased to enable easy but secure sharing of authentication and authorization information between organizations. Using the Security Assertion Markup Language (SAML), researchers are developing methods enabling one organization to share just enough information between systems to enable a transaction, without compromising privacy. Shibboleth, a project started in 2000 as an Internet2 middleware initiative, is an open-source project using SAML.⁷ Organizations using Shibboleth as a basis for designing new federated authentication and authorization implementations include InCommon⁸ and the UK Access Management Federation for Education and Research.⁹ To facilitate this kind of information sharing, the participating organizations need to share details about their security policies and procedures, so each may decide in advance whether it will trust the authentication assertions of the other. This kind of information sharing is accomplished most effectively via the policies and practice statements used in a PKI. For details on PKI and certificate requirements for cross-domain authentication, refer to Chapter 37 in this Handbook.

28.7 RELATIVE COSTS OF AUTHENTICATION TECHNOLOGIES.

One of the frequent responses from security professionals in discussions of identification and authentication using anything other than passwords is that the expense of buying new equipment is prohibitive. However, passwords are not free. In an analysis of the costs of managing passwords, RSA Data Security, makers of the SecurID token, estimated deployment costs (initializing user accounts) at about $12 per user over three years and management costs (replacing forgotten passwords and resetting locked accounts) at about $660 per user over three years. Worse yet, the well-established failure of most users to select strong passwords (i.e., those resistant to guessing, dictionary attacks, and brute-force attacks) makes passwords a weak authentication mode in practice. In comparison, token-based and biometric authentication are more readily affordable and more effective than passwords.¹⁰

28.8 CONCLUDING REMARKS.

Identification and authentication are the foundations for almost all other security objectives in cyberspace. In the past, these problems often were viewed as simple ones whose solution was assumed, before the real security issues came into play. Important standards for computer security were published and practiced without much attention to identification and authentication. In cyberspace, the problems associated with I&A are severe, and they have barely begun to be solved effectively. A robust, scalable identification and authentication infrastructure is vital to achieving security. Technologies such as tokens and biometrics hold out considerable promise, but their deployment requires infrastructure costs dominated by the cost of hardware for readers and the like. Meanwhile, passwords continue to be strengthened, as we better understand the real risks in using them and as we develop technical means to mitigate those risks. The fact that modern operating systems continue to provide simple password-based authentication, vulnerable to dictionary attacks, reflects poorly on the pace at which security technology is adopted in the marketplace. Looking to the future, one can predict that we will see a mix of passwords, biometrics, and tokens in use, perhaps in two- or three-factor configurations. Biometrics and tokens are likely to dominate the high-assurance end, while passwords will dominate the lower end.

One of the misconceptions that security specialists should seek to dispel is that identification and authentication are sufficient for improving public safety. However, assigning a reliable and nonrepudicable identity to someone is in no way equivalent to asserting the trustworthiness of that individual. In closed populations such as employee pools, employers can check the background of potential employees and monitor the performance of existing employees; under those circumstances, knowing someone's identity at the entrance gate may indeed improve security. However, when dealing with a large number of unscreened people, such as potential air passengers, confidently being able to name them tells us nothing about their trustworthiness. Having a clerk at a government office glance at fuel-oil invoices and a birth certificate before granting someone a photo ID is no basis for assuming that the carrier of the valid ID is an inoffensive traveler. As several writers have noted, unambiguously knowing the name of the suicide bomber sitting next to you in a plane is not a reasonable basis for complacency. Timothy McVeigh, the Oklahoma City bomber, was a perfectly identifiable citizen of the United States, but he committed his atrocity nonetheless.¹¹

Since September 11, 2001, the air transport industry has been a very public example of both the difficulty of strong identification and authentication and the use of identification and authentication as a public relations substitute for substantive security involving thorough passenger screening. The inherent difficulties of authentication are becoming evident to the lay public and to political and corporate leaders. It is very difficult, perhaps even impossible, to guarantee foolproof identification and authentication in free societies. As technologists, we realize that absolute guarantees cannot be achieved in cyberspace. Too many security professionals seek absolute goals, and too many security technologies are marketed as being stronger than they really are. Our profession will benefit greatly if we address practical problems with practical cost-effective techniques and develop a sound security discipline that contains, bounds, and mitigates the inevitable residual risk that we must face in any large-scale human situation.

28.9 SUMMARY.

Passwords are widely used in practice and will continue to be a dominant form of user authentication. There are many risks in deploying passwords, and a number of widely used password systems have serious vulnerabilities. Nonetheless, technical measures can mitigate the inherent vulnerabilities of passwords. Although it takes great skill and care, with our current understanding it is technically possible to build and deploy strong password-based authentication systems using commercial products. The truly inherent risks of undetected theft and undetected sharing can be largely mitigated by new technologies, such as intrusion detection systems. Undetected sharing may be deterred further by a system that couples high-value secret data, such as credit card account numbers, with passwords. Tokens are available to generate one-time passwords or to communicate directly with authentication systems. Although costs have been dropping, tokens are still not as widely deployed as early predictions suggested they would be. Biometric authentication has been implemented only infrequently and on a small scale but offers great potential, especially for high-security applications. Interesting new research and applications are extending the use of authentication (and authorization) over untrusted networks between federated organizations.

28.10 FURTHER READING

Anderson, J., and R. Vaughn. A Guide to Understanding Identification and Authentication in Trusted Systems (1991). “Light Blue Book” in the Rainbow Series, NCSC-TG-017; www.fas.org/irp/nsa/rainbow/tg017.htm.

Birch, D. G. W., ed. Digital Identity Management: Technological, Business and Social Implications. Aldershot, Hampshire: Gower Publishing, 2007.

Integrity Sciences. “Bizcard ZKPP: A Zero-Knowledge Password Proof with Pencil and Paper” (2001); www.integritysciences.com/zkppcard.html

Jablon, D., et al. “Publications on Strong Password Authentication” (2001); www.integritysciences.com/links.html.

Jain, L. C., et al., eds. Intelligent Biometric Techniques in Fingerprint and Face Recognition. Boca Raton, FL: CRC Press, 1999.

Kabay, M. E. “Identification, Authentication and Authorization on the World Wide Web,” 1998; www2.norwich.edu/mkabay/infosecmgmt/iaawww.pdf.

“One-Time Passwords.” FreeBSD Handbook, Chapter 14.5; www.freebsd.org/doc/en_US.ISO8859-l/books/handbook/one-time-passwords.html.

Radhakrishnan, R. Identity & Security: A Common Architecture & Framework for SOA and Network Convergence. London: futuretext, 2007.

Smith, R. E. Authentication: From Passwords to Public Keys. Reading, MA: Addison-Wesley, 2001.

Todorov, D. Mechanics of User Identification and Authentication: Fundamentals of Identity Management. Boca Raton, FL: Auerbach, 2007.

Tung, B. Kerberos: A Network Authentication System. Reading, MA: Addison-Wesley, 1999.

Vance, J., “Beyond Passwords: 5 New Ways to Authenticate Users,” Network World, May 31, 2007; www.networkworld.com/research/2007/060407-multifactor-authentication.html.

Wayman, J. L. “Biometric Technology: Testing, Evaluation, Results” (1999); www.engr.sjsu.edu/biometrics/publications_technology.html.

Windley, P. Digital Identity. Sebastopol, CA: O'Reilly, 2005.

Wu, T. “A Real-World Analysis of Kerberos Password Security.” Proceedings of the 1999 Network and Distributed System Security Symposium; www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf.

28.11 NOTES