Exploits & Weaknesses in Password Security

{LANG_NAVORIGIN} Authentication Passwords
Paul Gurgul 11/16/2004



This paper covers exploits in passwords and describes each tangent associated within the realm of administration security practices.

With an “out-of-box” operating system, re-usable passwords are entered each time a login is performed. The biggest problem with reusable passwords is that they are susceptible to a variety of attacks that have a single goal: to uncover the user's password. In the preceding chapter, this kind of security boundary was cited as a source of concerns. The login boundary is affected by three factors: the strength of the data provided by the user, the integrity of the data transmitted at the boundary, and safe communications at the boundary. A weak password is an example of the first factor. If the password is transmitted across a network, an adversary might be able to intercept and modify the value, validating the second type of concern. Finally, if the login programs are tampered with, and the boundary between the user and the computer becomes untrustworthy, the third factor is attacked. These three factors are targeted to varying degrees by the attacks described next.


Easily Guessed Passwords

The first weakness lies in the composition of the password itself. Passwords to avoid include the following:

1. Common names, especially relatives, coworkers, or dignitaries
2. Jargon words often found in a specialty area, such as the name of a football play
3. Simple strings, such as those composed of all the same character
4. Words found in dictionaries
5. Important numbers, such as your social security number, driver's license, birthdays, or vehicle tags

When choosing a password, pick one that is hard to guess and also easy to remember. Often, these two goals are contradictory. However, if you pick pronounceable strings mixed with numbers or special characters, you will be making the task of the attacker more difficult. Increasing the size of the space someone must search through to guess a password is your goal. Longer passwords are better because there are more combinations of letters to consider.


Brute Force Attacks

The most basic attack that can take several forms is brute force. First, the hacker can sit down at the terminal and perform an online attack. The adversary enters your username and tries to manually guess your password. Given unlimited opportunities, an adversary may be able to guess the password. Login guessing attacks are thwarted by configuring the operating system to limit the number of failed login attempts allowed for each user. After a threshold is reached, the account will be locked and that user will be unable to log in until the system administrator intervenes by resetting the password or unlocking the account in some other way.

Unfortunately, this defense policy allows for a denial of service attack. A malicious person could cycle through each user account on the system, exceed the failed login threshold, and lock out all of the accounts. The policy should be configured so that the root user, or another privileged user, is always able to access the system from a designated, physically secure console in order to correct the situation. To generalize, any authentication system should be resistant to denial of service attacks that lock out the system administrator. On computers with an external media device, such as a tape or a CD-ROM drive, the administrator can always boot the system from backup media, enter a limited computing environment known as single-user mode in UNIX, and take corrective actions. One can further deter manual guessing by injecting some randomness into the login procedure. For example, if an incorrect password is entered, the system can delay for a time interval before presenting the next login prompt. The time interval can be computed as an increasing function of the number of failed logins from that terminal device or might be configured as a constant value such as always delaying for two minutes after three failed login attempts for a single user. If increasing interval delays are used, another configuration value is needed to determine when to reset the interval to its initial state. A variation on the interval delay is to change the input time between keystrokes used to read the password.

Another defense involves locking the terminal itself after a configured number of failed login attempts. As in the preceding case, the terminal can be reset only by an authorized admin’. Some operating systems also provide an option for configuring which terminal devices individual users are able to use for login. A failed login attempt at an unauthorized terminal is usually not counted against the failed login threshold. With today's ubiquitous networked computer environments, some operating systems extend the notion of "authorized terminal" to include a range of valid network addresses.

Notice that these attempts to defend against manual guessing attacks are used only to deter the hacker. Failed login thresholds, delay intervals, and other defenses will not prevent a brute force attack from occurring. However, they will discourage someone from instigating a brute force attack and increase the difficulty of successfully executing an attack. Preventing a brute force attack from happening is nearly impossible. It is highly probable, though that one can prevent manual guessing attacks from succeeding. To increase the sophistication of the online brute force attack, the hacker can write a program to carry out the manual guessing steps. A dictionary of passwords is compiled and perhaps even customized for the penetration attempt. The program consults the dictionary when attempting to crack an account. Heuristics can be used so that the program adapts to the targeted host. For example, guessing that the password is the same as the username is a plausible first attempt.

The Internet Worm was able to crack a number of accounts throughout the Internet using the following heuristics for passwords (Ferbrache and Shearer, 1993):

1. No password
2. The username or the username concatenated with itself
3. Variations on the user's first name or last name-uppercase, lowercase
4. The username typed in backwards
5. A dictionary of 432 words chosen by the worm's author
6. The online UNIX dictionary if available

You might think that a programmed attack like this works only if the attacker is trying to login via a network using one of the many built-in ways in which operating systems provide for network logins. However, it is just as easy to detach a terminal from its cable and directly attach the cable into the back of a personal computer programmed to emulate a terminal. From this configuration, the hacker can run an automated attack that appears like a user attempting to physically login.

A more dangerous brute force occurs when the attacker is able to gain a copy of the stored password values. With this additional knowledge, an offline attack is possible. Two approaches are possible. In the first, the attack is still centered on repeatedly trying to guess the password on a victim machine. Your system will be unaware of any attempts by the user to guess passwords because all efforts are made on another system. If a UNIX password file is obtained, the attacker could use any number of collaborators to achieve offline guessing in parallel. Portions of the password could even be divided among the cohorts. The victims machine is configured by attackers so that the defense mechanisms, such as failed login thresholds, are disabled.

A second offline attack depends on a matching strategy. Instead of guessing passwords, the attacker computes a number of hashed password values in advance. The attack succeeds when a user's hashed password value matches one of the pre-calculated hash values. Tools to facilitate this approach are readily available for both UNIX and NT. Crack, developed by Alec Muffett, is widely relied upon by professional penetration testing teams to probe the suitability of user passwords on UNIX systems. Crack has been very successful at breaking many passwords. The arrival of L0phtCrack from Mudge www.l0pht.com showed that NT also was subject to the same kind of offline brute force attack. You might find it interesting that the infamous Internet Worm (which does not seem so infamous given the sensitivity of sites recently broken into) traveled with a mini-dictionary and password cracker.

You must assume that an attacker has more time to devote to hashing potential passwords than you have for managing your systems. Thus, this attack is particularly threatening if your users are choosing passwords from a small search space, such as passwords of only three alphabetic characters. Various statements about the difficulty of breaking the UNIX password hash have circulated in the community for years. Often one will encounter a statement describing the probability that a password can be cracked to be nearly impossible. Such statements are made from a theoretical basis and cite the length of the password, usually in bits, and how hard it would be to exhaustively search the entire space of these bit strings. Indeed, the usual phrase is that an exceedingly powerful computer running for the known life of the universe would not be able to complete the search. What these statements do not consider are the practical aspects of password guessing.

Users repeatedly choose weak or easily guessed passwords. Hackers and password crackers use this information to narrow the search space and substantially reduce the complexity of the problem. Although in theory, guessing an 8-character password from the universe of 8-character passwords is impossible, in practice hackers are quite successful at it!

A good defense against offline brute-force guessing is to use stronger passwords. You also need to protect the password repository, whether it is a file on a local computer or database on a central server. If the computing environment in which you are working will support encryption of the password file or database, you should take advantage of this feature, too. If the password file is stolen, mounting offline attacks against an encrypted file will be much more difficult.

If a user is required to remember different passwords for several systems, chances are that the passwords will be written down. Hackers who physically reconnoiter a site have favorite places they inspect for written passwords such as under the keyboard, on a nearby filing cabinet, or on the back of the monitor. Needless to say, passwords that are written down are fairly easy to crack.

It is interesting that despite the many additional defense mechanisms in operating systems to deter brute-force attacks, many computers today are cracked because of weaknesses in the password itself. Ignoring pleas from security experts, countless books, and trade magazines, users still continue to choose passwords that are easily guessed.


Social Engineering

Not all password threats are based on guessing or cryptographic techniques. Many hackers report that the easiest way to break into a system is social engineering (Littman, 1997; Knightmare, 1994). You would be amazed at how freely information is given over the phone without proper authentication between the parties. The lore of hackers is filled with tales of gullible users being conned into giving away their passwords, the passwords of their superiors, or other information that can be used to penetrate a network.

Sometimes, the social engineering attack requires physical surveillance of the work site. To accomplish this surveillance, an opponent impersonates someone from a maintenance company, courier service, or even a pizza delivery person to gain access to the site. Once inside, personal information about the target person can be gleaned from pictures on the desk, by sifting through the trash, or by listening to careless office gossip. Some even go so far as to dig through trash containers on the company's premises. Security guards who stumble upon these sifters are easily repelled when the hacker explains the activity as collecting aluminum cans, searching for a lost article such as a watch, or desperately trying to retrieve a lost report. Stories have been told of security guards helping a hacker find useful information in these situations (Knightmare, 1994).

The shoulder surfing technique identified earlier is also a favorite technique. Try watching a friend type in a password. You will be surprised how easy it is to pick up at least a few characters. Remember, any information is useful. Knowing the password length and a few of its characters also can help reduce the search space. If the password is particularly difficult to type, or if the user is unaccustomed to keying in the password, shoulder surfing is made easier by the slow keystroke pace. Social engineering tricks also include distracting a user while the password is being entered. Verbal information processing can reduce the keystroke rate of a user. In other words, if the attacker is chatting in your ear about last night's football game, the time it takes you to enter your password will be increased.

When sufficient background material is obtained, the fun begins. The biggest problem the hacker faces is deciding which approach to use for social engineering. A particularly successful approach is for the attacker to call the target user and impersonate a superior. If the perpetrator can act convincingly, the hapless employee probably will respond automatically to any request. An alternative is to call a powerful network or system administrator over a period of time and build rapport by appealing to this person's ego.

For example, hackers have reported calling site experts with faked problems only to gradually develop a "friendship" with the unsuspecting soul on the other end. Enough trust has been built up to trick the victim into divulging information useful for penetrating systems, even if passwords were not obtained. At one recent hacker conference, a successful social engineering attack was carried out via telephone as part of a keynote address. In order to avoid breaking any serious laws, the speaker disconnected the victim only seconds before some useful secrets were disclosed.

The purpose of a social engineering attack may be to simply gain additional information that makes password guessing easier. Almost any information is useful to an attacker. Names of children, favorite hobbies, project names, birthdays, and other personal data can help narrow the search space for a brute-force password attack. A popular but predictable technique that some people use to "improve" the strength of passwords is to replace some characters with numerals. For example, the password "cocoon" would instead be "c0c00n". With respect to computer search speeds, this additional twist does not add significantly to the password combinations the cracker must test. Notice that the only defense, if you rely on reusable passwords, is to educate site users. Periodic reviews and trials can ensure that employees are complying.


Trojan Horses

Every computer science major has learned how to leave a login Trojan Horse on a system. Before logging off the system, the perpetrator starts a problem that displays a login prompt and waits for a victim. The username and password entered into the Trojan Horse are logged to a file or mailed to a collecting account. Usually, the Trojan Horse fakes some type of problem and exits. The operating system then takes control and displays the true login prompt. Most users would assume that they had entered a password incorrectly or that some other glitch occurred in the system. Not surprisingly, this attack can be very fruitful.

The temporary Trojan Horse login succeeds because of a flaw in the login authentication protocol described so far. The user is required to authenticate to the computer, but the login program is assumed to be legitimate. To circumvent this problem, secure operating systems provide a secure attention key (SAK) sequence. The NT operating system instructs the user to enter Ctrl-Alt-Del to initiate a trusted path with the operating system. Most UNIX systems also provide a SAK.

When this special key sequence is pressed, the user is assured that a clean environment is made available for login. For example, the system will detach any processes that are attached to or running on that terminal. What happens to these processes depends on the operating system implementation. The net result is that there will not be a chance for the previous user's processes to act as a login impostor.

A more serious threat is replacement of the login program in the system itself. This attack depends on circumventing the system's access control mechanisms because login and other I&A routines are part of the TCB. A hacker who manages to install a permanent login Trojan Horse can gain multiple username and password pairs. It is unlikely that only the login program was replaced. Trojan Horse versions of other security enforcing programs are certain to be found as well.


Network Sniffing

Many network protocols were designed with the assumption that users could be trusted or that the network was trustworthy. Precautions in protocol design were not always taken for defending against network eavesdropping. Network traffic monitoring is the electronic equivalent of shoulder surfing. A network sniffer is a program, or dedicated device, capable of capturing all traffic made available to one or more network adapters. Any data sent in the clear across the network is captured and inspected for usefulness. Countless network sniffers are running throughout the Internet today.

Network sniffers are freely available in the public domain (see Anonymous, 1997 for a comprehensive list) or can be purchased as part of products such as RealSecure from Internet Security Systems. A user who has access to a personal computer connected to a network can easily install a sniffer program. Most sniffers are sophisticated enough to selectively find passwords used for network logins. The attacker does not need to monitor every packet traversing the network. Assuming that the communicating systems rely upon reusable passwords for authentication, the person sniffing network traffic can effortlessly gather passwords to be used for later attacks. No evidence of this activity will be found on the attack targets, as was the case for online brute-force attacks.

Network sniffing is not limited to watching for passwords used during the authentication phase of a network login session. Because e-mail and other document delivery systems might contain lists of passwords, it is worth the effort to capture and scan these data forms as well. Remember that a new user must acquire the initial password from the security officer in an out-of-band manner. Often, the method chosen is e-mail, especially inside of private corporate networks. Employees are often required to sign agreements declaring that they will not engage in network sniffing or scanning. Because many computer crimes include an insider, the threat of legal consequences does not always outweigh the opportunity for financial reward.

Many private corporate networks also are accessed by contract vendors, who in turn may not adhere to the same restrictions. A successful social engineering attack could land a planted a network sniffer on your network. The sniffer could periodically send passwords via e-mail to an external system. For these reasons, you should assume that passwords which are sent across a network in cleartext form have been compromised.


Electromagnetic Emissions Monitoring

Electromagnetic emissions also have been exploited as a means for sniffing passwords, albeit in a different wave spectrum than network traffic. Despite efforts by various standards agencies to limit emissions from monitors and even storage devices, surveillance of these data sources is a very serious threat. The U.S. TEMPEST standard is one guideline that manufactures must follow to reduce electromagnetic emissions in an effort to eliminate this attack. The general idea behind TEMPEST is to shield devices from emitting a strong signal. In some cases, an individual room or an entire building is built to the TEMPEST standard.


Software Bugs

Sometimes, the operating system does all the hard work for the hacker. Software bugs continue to be a major source of security problems. For example, a recent bug in the Solaris operating system made the hashed password values available to anyone on the system. One of the network application programs could be forced to end abnormally, and as a consequence, that program would dump its memory contents to disk in a core file (to aid in debugging the crash). Users with no special privileges could force the program to do this. The core file contained copies of the hashed password values that normally were stored in a shadowed file. The information could be used as input to Crack for an offline brute-force attack.


Ideas for Improving Reusable Passwords

If you are constrained to relying on reusable passwords for I&A at your site, consider these ideas. Good security practices dictate that each password be subject to an aging rule, such as expiring the password when it becomes 180 days old or after it has been used 265 times. Similar rules should be followed for password composition, requiring that passwords include uppercase, lowercase, numeric, and even some special characters. Another composition recommendation is to limit the number of repeated characters in a password, whether serially repeated or not. To ensure that an attacker must search a large number of alternatives, the password should be the maximum length permitted on the system. Unfortunately, most UNIX systems only support 8-character passwords.

Another password rule is to limit similarities between the user's previous password and the newly chosen one. You could require that at least six of the characters in the password be different from those used in the previous password. Controlling password history is also a good idea. Some operating systems allow the administrator to configure how many password changes a user must endure before the same password can be reused. To prevent the user from choosing a temporary new password several times until the threshold is reached, a configuration value also is provided for a minimum password age. The user cannot change the password until the minimum age has expired.

The system also can generate passwords for users. Two problems are encountered with this approach. If the password is difficult to guess, the tradeoff is that you will find users writing down the complex strings. On the other hand, if the password generator creates pronounceable strings that fit a particular grammar, an attacker can use this information to narrow the search space. A hacker also can proactively check for passwords as they are chosen by users. Ideas for proactive password checkers can be found in the literature (Stallings, 1995; Bishop, 1993). Logical choices include modifying the change-password routines to invoke programs that compare the user's choice with dictionary entries.

One additional idea is to require each user to enter more than one password value. That is, authentication would be based on something you know and something you know. Although this method is stronger than a single reusable password, it still suffers from the problems already described. In terms of algorithm complexity, guessing twice as many passwords is negligibly harder for a password cracker.

As you probably have guessed, significantly improving the security of I&A at your site means foregoing reusable passwords. For example, instead of requiring a user to know two passwords for authentication, it would be better to base authenticate on two values selected separately from something you know, something you have, and something you are. Perhaps, you have seen movies in which an employee first inserts a badge into a reader and then also keys an access code into a keypad. Here, authentication is based on something the user has and on something the user knows. Either single authentication item alone is insufficient for gaining access to the target environment.

You will learn about mechanisms that avoid reusable passwords or require multiple authentication values in a few moments. Before doing so, let's pick up the earlier discussion path and expand your knowledge of authentication servers. Because many improvements to I&A require authentication servers, knowing how a server such as Kerberos works will help you evaluate alternatives. Before reading about Kerberos, you might want to glance through the sidebar, "A Cryptography Primer," if you are a novice to cryptography. More thorough treatments of cryptography can be found in Schneier (1996), Denning (1983), and Koblitz (1994).


Improving upon I&A with Authentication Servers

In this section, you learn how authentication servers can be used to solve I&A problems in distributed systems. Specifically, third-party authentication based on Kerberos and X.509 certificates is described.


Third-Party Authentication

The goal of a third-party authentication system is to provide secure communications between previously unknown entities. When MIT started the Athena project to deploy a number of distributed systems across a large network, they immediately realized that I&A was the initial weakest link in security. To solve their problems, researchers developed the Kerberos authentication system. Now widely deployed at various sites, Kerberos provides a third-party authentication server across heterogeneous operating systems.

Another third-party system described in this section is based on X.509 digital certificates. One of the drawbacks of Kerberos is that to date it has relied on secret-key technology, or symmetric cryptography, for I&A between entities. Lately, though, extensions have been proposed to Kerberos to support X.509 certificates. The X.509 standard is part of a large body of standards developed by the International Standards Organization (ISO) aimed at solving distributed computing problems. X.509 certificates are based on public key, or asymmetric cryptography, which overcomes some of the critiques of Kerberos mentioned in the following section.


A Cryptography Primer

Because cryptographic concepts are used throughout the remaining sections of this chapter, a few definitions will be helpful. Cryptography can be used to provide confidentiality, integrity, authenticity, and nonrepudiation. To begin with, cryptography relies on encryption to provide confidentiality of data. A secret key is used to encrypt the data according to some algorithm. The concerned party assumes that the details of the cryptographic algorithm are publicly known. Therefore, confidentiality is maintained only if the secret is not divulged or discovered and if the algorithm is sufficiently strong to resist attacks. More specifically, the algorithm must be such that decryption without the secret key is computationally infeasbile and that discovery of the key is equally difficult even if the attacker is given significant amounts of cleartext and ciphertext.

A distinction is made between symmetric cryptography and asymmetric cryptography. The same secret key is used for both encryption and decryption in symmetric cryptography. Different keys are used for encryption and decryption in asymmetric cryptography. Thus, symmetric cryptography requires that the communicating parties share a secret key; whereas asymmetric cryptography requires at least one key pair for successful communication.

Many popular symmetric encryption algorithms are used, although DES is the most widely known and deployed. RSA public-key cryptography based on work done by Rivest, Shamir, and Adleman (1977) is the famous example of asymmetric cryptography. A recurring and difficult problem in cryptography is distribution of the initial shared secret. With symmetric cryptography, the complexity of the problem increases as the number of communicating parties grows. Public-key cryptography partially eliminates this problem because the keys used in the key pair have interesting mathematical properities. One member of the key pair, the public key, can be broadcast to a broad audience in any desired fashion. The other half of the pair, the private key, is kept secret by its owner. The keys are mathematically related so that if one key is used for encryption, the corresponding key can be used for decryption using the RSA algorithms. Also, it is computationally infeasbile to derive one key given the other.

To communicate with a stranger in a secure fashion, you would first obtain this person's public key, encrypt the message, and forward the message using any preferred means including unsecure networks. The recipient decrypts the message using the private key. A message sent from the stranger is encrypted with your public key and decrypted by you with your private key when it arrives.

Because no key pairs are alike, you can first encrypt a message with your private key and then encrypt the result with the sender's public key. The doubly encrypted message after being delivered to the addressee is first decrypted with the private key of the recipient and then decrypted with your public key. In addition to other benefits, this protocol can be used to assert that no one other than you could have possibly sent the original message (nonrepudiation). Cryptography also is used to provide digital signatures using this technique. That is, if you sign a message using your private key and a cryptographic hash function, or if you encrypt a message with your private key, you cannot later disclaim the results.

Because public-key algorithms are not as fast as symmetric algorithms, both approaches are often employed in communications protocols. Public-key techniques are used to deliver a limited secret key that is then used for the communication session. Depending on the amount of secrecy required, you can even change the key on each message exchange to obtain one-time password support.

An interesting post to the Internet suggests that the U.S. and U.K. governments were working on public-key techniques in 1970 and possibly earlier.


Kerberos

Kerberos is a centralized server for authenticating entities and for enabling secure communications between entities in the network. To accomplish this, Kerberos provides an Key Distribution Center (KDC) that fulfills two roles.

First, the KDC contains hashed password values that are used to authenticate users during login. Next, the KDC also distributes a shared secret to communicating parties when a secure session is needed. The secret is used for encryption or message integrity computations when the parties exchange messages. The Kerberos server is assumed to be running on a physically secure server in the network.

To prevent password cracking attempts, information stored in the server's database is encrypted using a secret chosen at installation time. Remember that this type of encryption was one of the recommendations for improving the security of reusable passwords.

Kerberos relies on reusable passwords to initially authenticate entities such as users in the network. When a user completes the login process, though, the password is no longer needed. Instead, the KDC generates a unique session key that is the shared secret between communicating entities. A given session key might encrypt several different messages between the two ends of the communication channel.

However, when the last message is sent, and the session is terminated, the session key can be discarded. This process is more secure than relying on the same secret for each communication session between two endpoints. Also, the Kerberos server "forgets" any session keys it has generated for other entities to use.

Unlike NIS, which is really just a different data store for the same information found in /etc/passwd or /etc/group, Kerberos is an alternative I&A repository that introduces its own notions of subjects and objects. The authoritative scope of a Kerberos authentication server is called its realm. The subject in Kerberos is called a principal. More than one instance of a given principal can exist, so the pair {principal, instance} uniquely defines a subject in a Kerberos realm. Principals are identified using a string name, just like the username in UNIX or NT. The KDC server shares a master key secret with each principal in the realm. For simplicity and without loss of generality, the remaining discussions assume that a single instance of each principal is in the realm. By introducing its own notions of subjects and objects, Kerberos is adding a new security model to your site. For this reason, you will want to critically examine how Kerberos works and how it is integrated into your site.

The KDC is further divided into an Authentication Server (AS) and a Ticket Granting Server (TGS). The responsibility of the AS is to authenticate the identity of entities in the network. Secure dialogues in a network are accomplished when the communicating parties share at least one secret that can be used to encrypt and decrypt the information they exchange. The Kerberos TGS is responsible for generating a unique session key to be shared between two parties. The parties then use this session key to encrypt their messages or to guarantee the integrity of messages sent. Both the TGS and the AS are combined into a single server in Kerberos. The distinction between the AS and the TGS is conceptual and based on the role being played by the Kerberos KDC server at any given time. Therefore, the term KDC sometimes will be used to jointly refer to both the AS and the TGS.


Third-Party Authentication Steps

Consider the high-level steps and requirements for authenticated and secure communications between two entities using Kerberos. Assume that X wants to communicate with Y in a network. X and Y could be users, software processes, or workstations. X contacts the KDC with a request for a secure session with Y. Because the KDC knows the secrets for both X and Y, and neither X nor Y knows the other's secret, the KDC can rely on cryptography to fulfill the request.

1. A random session key SKx,y to be shared by X and Y is generated by the KDC.
2. Several values are combined to form a ticket that is needed to prove X's identity to Y and to deliver the shared secret securely to Y. The ticket includes SKx,y, the principal name for X, and some other fields. Finally, the ticket is encrypted by the KDC with Ky, the secret key of Y, so that only Y can decrypt the result.
3. SKx,y and the ticket are encrypted by the KDC with Kx, the secret key of X, so that only X can decrypt the result. The encrypted ticket and session key are sent from the KDC back to X. Let the notation { SKx,y}Kx represent the encryption of the session key with the secret key of X and the converse for Y.
4. The KDC has sent SKx,y and { SKx,y}Ky encrypted with Kx to X, who decrypts the message to obtain the session key SKx,y. Using the preceding notation, the message received by X is { SKx,y and { SKx,y}Ky}Kx.
5. X sends { SKx,y}Ky and the rest of the ticket encrypted with Ky to Y, who likewise decrypts this message to obtain the session key. In looking at the contents of the ticket, Y also deduces that this message could have been created only by the KDC, and that X is indeed legitimate. For example, part of the ticket, encrypted with Ky, contains the principal name X. When X sends the ticket to Y, the principal name X also is included as part of the message header. Y compares the value in the header with the decrypted value from the ticket to help verify the identify of X. Again, because the ticket was encrypted by the KDC using Ky, and only the KDC could have known this secret, Y can trust that the identity of X is authenticated by the KDC.
   X and Y now share a secret SKx,y which can be used for secure communications. Y knows that the session key received in the message from X must be valid because only the KDC, which shares Ky with Y, could have appropriately encrypted the ticket containing the session key. Notice how both X and Y must trust the KDC to authenticate each other. How did the KDC verify the identity of X in the first place?

Kerberos Login

Because the Kerberos KDC acts as an authentication server, it controls its own security domain or model. A user or entity that wants to communicate in the domain of Kerberos must first establish an identity with the Kerberos server. The Kerberos administrator adds names, passwords, and other information for each of the principals in the realm. Only the system administrator of the secure Kerberos server should be allowed to modify these entries. After a user is added as a principal in the database, login to the Kerberos environment is possible.

Assume that X is a user. The login process begins in the familiar fashion when the user sits down in front of a terminal displaying a login prompt. X enters a username that the login program captures. The login program klogin, in the role of Kerberos client, sends an authentication request containing the username and current timestamp to the KDC. The KDC and the login workstation could be the same system, but it's more interesting to think of them as different nodes in the network. If the user enters an incorrect username, the KDC responds to klogin with an error.

If the user enters a correct username, the KDC sends to klogin a response message encrypted with Kx, the secret key of X. As you might suspect, Kx is a DES key derived from the user's password and stored in the KDC database. At this point, the AS component of the KDC has fulfilled its role. That is, the KDC is not involved from this point forward in completing the authentication process. The program klogin assumes responsibility for completing authentication by asking X for a password and then converting the password into a DES key. The result will be equivalent to Kx if X entered the correct password. An attempt is made by klogin to decrypt the message received from the KDC using the hashed value computed from the password.

If the decryption is successful, X has been authenticated and can proceed to use the system. Note that the password itself is never sent in the clear over the network to the KDC.

Of special importance in Kerberos Version 4 is the protocol requesting the user's password. This step is not initiated until after klogin receives the first response from the KDC. When the user enters an invalid username, the KDC responds with an error to klogin. When the user enters a correct username, the KDC responds with a message encrypted with the secret key of the user. Only after this response is received will klogin prompt for the password.

Kerberos V4 introduces this delay in retrieving the password in an attempt to limit the amount of time the password string is kept in memory. This approach is laudable because storing a password in memory even for a short time might enable a concurrently running rogue program an opportunity for password theft. However, as you will see, this protocol also opens Kerberos V4 to password guessing attacks.


Analysis of klogin

The login scenario described previously is actually more complex than the overview indicates. In this section, you learn additional details about the messages exchanged in Kerberos.

Recall that the TGS is the part of the Kerberos server responsible for generating shared session keys. The TGS is itself a secure Kerberos server, named krbtgt, which shares a secret with the KDC. Anytime X wants to initiate a secure conversation with another entity in the network, X must contact the TGS and ask for a new session key and ticket. In order to communicate with the TGS, X must establish trust with the TGS by completing the login process.

The TGS is the only place where a principal can obtain a session key, and the only way to gain the right to request a session key from the TGS is by logging in to the KDC. Remember, too, that the TGS is just a special part of the KDC. So, when you read that a message is exchanged with the TGS, it is really the KDC that receives all of the messages for the Kerberos server. Here are the login steps assuming again that X is the user attempting to authenticate to Kerberos.

1. X enters the username X in response to the login prompt. For simplicity, assume that the Kerberos principal name for X is the string X.
2. klogin sends an authentication request to the KDC. The message is not encrypted. Fields in the message include the current timestamp on the login workstation, the principal's username X, and the name of the principal service with which klogin wants to communicate. The service name is krbtgt, and this string value is included in the message. This process will be important later when you learn about one attack against Kerberos.
3. The KDC verifies that X exists in the database and obtains Kx, the secret key for X. A reply message is encrypted with Kx and returned to klogin. The encrypted message contains the principal name X, the server name krbtgt, the original timestamp sent in the request from klogin, and some other fields that enable X to verify that the response came from the KDC. The encrypted message sent by the KDC also contains a session key SKx,tgs and a ticket granting ticket (TGT). The session key SKx,tgs is used by X to securely communicate with the TGS.
   The klogin program obtains the password from X as before and attempts to decrypt the message received from the KDC. One of the indicators for successful decryption is when the name of the requested service sent back by the KDC matches the string krbtgt. If decryption is accomplished, login is complete, and the user X now starts communicating with other principals.

A More Detailed Look at a Session

At some point in the future, X will want to talk to another principal such as Y. The TGT plays an important role in this process. Normally, when two principals exchange a ticket, the lifetime of the ticket is very short to prevent replay attacks. If the ticket's lifetime is too long, an attacker might be able to use the ticket at a future time, impersonate one of the principals, and trick the other principal into divulging information. Therefore, tickets normally expire within a few seconds, although the limit is configurable by the Kerberos administrator.

On the other hand, the TGT has a longer lifetime because a principal needs to reuse it each time a new session key is needed. When a TGT is renewed or when a new TGT is obtained , the user must complete the I&A process again with the Kerberos server. This process requires reentry of the password. Most sites limit the TGT lifetime to eight hours or less for a login user.

When login is complete, a principal has both SKx,tgs and the TGT. At a minimum, the TGT contains the value {SKx,tgs}Ktgs, or the session key for use between the TGS and X encrypted with the secret key of the TGS. All of this information was obtained from the KDC. What happens when X wants to communicate with Y?

1. X sends a request to the TGS asking for a session key to communicate with the principal Y. The message that X sends contains several fields. First, it contains the TGT that can be decrypted by the TGS using Ktgs to obtain the shared session key SKx,tgs. The message also includes information, such as the principal name of Y, encrypted with SKx,tgs. When the TGS gets the shared session from the TGT, it can decrypt this additional information.
2. The TGS generates a new random session key, SKx,y, to be shared between X and Y for their session. The TGS asks the KDC to use Ky to encrypt this new session key SKx,y and some other values into a ticket Ty. The TGS then returns to X the new session key and the ticket Ty encrypted with SKx,tgs. To be clear, SKx,tgs is the session key for secure exchanges between X and the TGS. SKx,y is the session key to be used for secure exchanges between X and Y.

Having received both SKx,y and Ty from the TGS, X now can start the dialogue with Y as before. One detail that needs to be mentioned is that the initial message X sends to Y includes Ty and an authenticator. An authenticator is used for X and Y to prove that they are who they claim to be. Principal Y decrypts Ty and obtains the session key SKx,y. The authenticator was encrypted by X using this session key and therefore can be decrypted by Y only through using the same session key. The authenticator includes the sending principal's name X and the current timestamp. Y verifies the identify of X by comparing the decrypted timestamp with its own synchronized timestamp. Because the timestamp only can be decrypted with the same session key used for encryption, Y verifies X.

If bilateral authentication is required, X can request this of Y. To meet this requirement, Y takes the timestamp from the authenticator, increments the timestamp by one, encrypts this value with the session key, and sends the result back to X. The incremented timestamp can be decrypted and verified by X using the session key. Figure 2.4 provides a graphical simplification of how two parties use a KDC to begin a secure session.

To summarize, Kerberos provides for two-way, third-party authentication. The key points are as follows:

1. A KDC shares a secret with each principal.
2. Each principal authenticates to the KDC using this shared secret or password-derived value.
3. When an originating principal wants to securely communicate with a receiving principal, the originating principal obtains a new random session key from the KDC.
4. The KDC also sends the originator a ticket that is the session key encrypted with the secret of the receiving principal.
5. The originating principal sends the ticket and an authenticator to the receiving principal.
6. The receiving principal decrypts the ticket and obtains the session key. This key is used to decrypt the authenticator and to verify the identity of the originator.
7. If bilateral authentication is required, the receiver can demonstrate knowledge of the shared session key by encrypting a modified timestamp from the authenticator and returning this value to the originator.

Integrating Kerberos and UNIX Login

This login process identifies and authenticates the user X into the Kerberos environment, but what does this have to do with a login session on UNIX or NT? Recall from the previous discussions that in UNIX, for example, your UID and GIDs determine who you are on the system and what you can do. In the Kerberos login described, your identity is based on your principal name and your Kerberos password. Environments that integrate UNIX or NT with Kerberos can be confusing because you can have two identities. Because both Kerberos and UNIX implement their own security models, a separate identity is used in both security domains depending on the situation.

(Consider the following scenario)------------

If you have a personal UNIX workstation, you will have an account on that system. When you login and start running programs, the UID and GIDs assigned to you form your credentials. All of the programs on that system look at your UID and GIDs to decide what you are permitted to do on the system. Kerberos is a completely different environment. In order for a program to take advantage of the features in Kerberos, that program must be instrumented to or enabled for Kerberos. For you to interact with a Kerberos enabled program, you must have a Kerberos credential. The only way to obtain a credential is to authenticate to the Kerberos server. None of the programs delivered with your UNIX system will by default be able to do anything with your Kerberos credential unless they have been modified to do so. Although, Solaris provides some UNIX network applications that are enhanced to work with Kerberos.

Because the operating system security kernel does not make decisions based on Kerberos credentials, think of Kerberos as an application level framework. Applications are written specifically to work with Kerberos, and these applications sit on top of the operating system. Many of these applications are servers that run with root or special privileges on the operating system.

To show you how confusing this can be, the Kerberos enabled application understands and interacts with Kerberos security internally, but the application itself is running within the security context of the UNIX operating system! When you remember that Kerberos is made of several different programs running on various operating systems, this concept does not seem so hard to grasp. Still, it's an interesting dichotomy that surfaces with security products.

Kerberos augments the security of most operating systems, rather than replacing operating system components. Because Kerberos was designed to improve distributed systems security, it's not surprising that this is the case.

Operating systems that have been integrated with Kerberos rely on modified login programs or procedures. If the change is transparent to the user, then login will create a shell with your credentials and obtain your Kerberos credentials from the server. In this way, programs that make access control decisions based on your UID and GIDs will work as usual, and any programs needing your Kerberos credentials can obtain these where they are stored on the local system. If integrated properly, the authentication step will not rely on finding your password in /etc/password (or the shadow file), but will use the Kerberos server to verify identity. In this way, the integrated system is taking advantage of a centralized store for user passwords. A word of caution is needed, though. Unless all login paths to the operating system have been modified to query the Kerberos server for authentication, leftover entry points into the system will exist. These leftover paths will use the information in /etc/passwd and might introduce weaknesses into your system.


Benefits of Kerberos

Notice a couple of the security features provided by Kerberos. No passwords are shared between any of the principals. Only the KDC knows the hashed password values for the principals. The KDC additionally encrypts the hashed password database to strengthen security.

A different shared session key is used when X communicates with the TGS than when exchanging messages with Y. Similarly, if X were to initiate sessions with other principals, the shared session keys would be random and different. Assuming that the technique used to generate random session keys is sound, it is computationally infeasible for an adversary to guess a session key.

Identities are verified by showing knowledge of a shared secret without divulging the secret itself in the clear over the network. Both X and Y possess the same shared secret distributed by the trusted KDC server. Cryptography and checksums are used to protect the integrity of the tickets. Thus, an attacker cannot attempt to modify a ticket in transit to trick one of the principals into using the wrong session key.

Although the improvement beyond standard UNIX or NT login authentication is not that significant with Kerberos, the features it provides for secure communications between principals in a distributed network are substantial.


Complaints and Attacks against Kerberos

One of the chief reasons for analyzing Kerberos in detail is that many of the topics discussed in the remainder of this book require authentication protocol exchanges between two or more entities in a network. Kerberos is really a simple system to learn first. Many more complex cases and environments need to be considered. Knowing problems with distributed protocols can help you avoid costly mistakes. To see how intricate distributed authentication protocols can be, consider some of the following arguments against Kerberos (Bellovin and Merritt, 1991; Kaufmann, Perlman, and Speciner, 1995).

1. Each software component must be modified to work with Kerberos. If you want to use only Kerberos to improve login security for your UNIX or NT box, you are getting more than you need. Kerberos is designed for much broader tasks than this.
2. File systems such as the Andrew File System (AFS) have been built around the Kerberos protocol. However, Kerberos itself does not provide access control or authorization services. Of course, it was never intended to provide this feature.
3. Systems in a Kerberos network require synchronized time clocks. Secure distributed time services are thus a prerequisite for Kerberos to operate properly.
4. You should be able to easily see how a Kerberos user principal can enter a password to authenticate to the KDC. Kerberos was designed to provide trusted third-party authentication for other principals, such as software servers and workstations. For these inanimate principals to prove their identity to the KDC, the principal's password must be stored on disk in the /etc/srvtab file. This file could be compromised if the system is attacked.
5. On multiuser systems, principals' tickets are stored in a temporary directory that can be read by any user. This information could be useful to a hacker for offline password cracking.
6. Kerberos relies on the User Datagram Protocol (UDP), which is often blocked at the firewall. As such, it is difficult to run Kerberos between sites protected by a firewall.
7. Kerberos V4 binds tickets to a single network address for a workstation or server. Thus, a system with multiple network adapters will have problems using tickets.

A few problems with the protocols described in the preceding list also affect Kerberos V4. The most often lamented feature is the login protocol.

Remember from previous comments that klogin will send an initial request to the KDC containing the principal's name and some other values. If the principal name is valid, the KDC sends a reply encrypted with the secret of the principal. Because the initial request information is transmitted in the clear, and the Kerberos code is freely available, an adversary who knows the names of principals can send this initial request and obtain the encrypted reply. This reply then can be used as input for an offline password cracking attempt. If the decrypted reply contains the string krbtgt, the attacker has uncovered the principal's password.

Someone using a network sniffer also can capture the entire initial request packet containing the principal name and current time to further validate decryption. Principal names also can be obtained through techniques such as social engineering, network sniffing, or electronic mail. Once again, the system is only as strong as the reusable passwords chosen by users.

Kerberos V4 also suffers from a bug that allows one to perform offline password cracking even if the name of a principal is not known (l0pht 1997). If the KDC receives an improper UDP packet, it will return an error containing the name of the last principal to request a TGT along with the realm name. To acquire a list of principal names just repeatedly query the server with incorrect UDP packets and store the resulting messages. These names can be used to attack the system as described previously.

If the AS is not configured to limit online password guessing attempts, you can try password cracking interactively. Should this approach fail due to limits on failed login attempts, the attacker can always turn the hack into a denial-of-service attack by sequentially locking out all principals.

Some characteristics of Kerberos have not been discussed in detail. For example, Kerberos servers in different realms can establish trust relationships and perform cross authentication services. Because the cooperating KDCs cannot dynamically enter a password as a user might, cross-realm authentication relies on the stored secret problem already identified.

Another problem with Kerberos lies in the authenticator. Bellovin and Merritt (1991) describe how an attacker might be able to use an authenticator in a replay attack. Also, any successful attempts to alter the allowable time skew between nodes opens up possibilities for authenticator replay attacks. Previously expired authenticators could be used again.

Incrementing the timestamp by one for bilateral authentication also is not without its problems. A better choice would be to use a challenge-response mechanism. When a Kerberos client wants to verify that a Kerberos server holds the session key, the client should ask the server to generate a random challenge or nonce. The server would encrypt the nonce with the session key and send it to the client. The client responds with some function computed on the nonce, encrypts the result, and returns the value to the server to prove knowledge of the session key. Of course, the client and server must agree on the function (which is "increment by one" in Kerberos V4).

A general rule of thumb for mutual authentication is that something in a message should differentiate which side it came from (Kaufman, Perlman, and Speciner, 1995). Either each side should use two different keys (one for sending and one for receiving), or each side should perform a different algorithm when responding to a challenge.

In Kerberos, there is no way to adequately determine whether the first reply from the KDC to klogin is genuine. Therefore, at least a denial-of-service attack can be launched against the login workstation by sending "principal not found" from another node. The hacker succeeds when the forged message arrives at the login workstation before the KDC's response. This is an example of a race condition. With today's open network protocols, it would be possible to flood the KDC with network packets to slow its response time. An attacker who knows the secret keys of the principal and the TGS can trick both into using a compromised session key by spoofing the login process.

Finally, weaknesses in the random number generator of Kerberos V4 allowed secret keys to be guessed rather easily in some circumstances (Dole, Lodin, and Spafford, 1997). Clearly, creating a secure, distributed authentication system is difficult. The keepers of Kerberos listened to these criticisms and problems and made many changes in Version 5.


Kerberos Version 5

The core of Kerberos was completely rewritten for Version 5. The goals and overall design remained the same. A third-party KDC was used to generate session keys in the manner already described. However, Version 5 relies on greatly enhanced message formats based on Abstract Syntax Notation 1 (ASN.1). A programmer can use ASN.1 to accurately identify the data type and length of all data values used in a message. This capability improves the integrity of data in Kerberos messages as well as allowing for more options in message formats.

Rather than describe all of the advantages and new features of Kerberos Version 5 here, you are advised to visit the Kerberos ftp site at for papers and copies of the Kerberos documentation. Commercial versions of Kerberos can be obtained from Cygnus, Veritas, and Cybersafe to name a few.

One important difference between Kerberos V4 and V5 is the way login occurs. In Version 5, the user is required to prove knowledge of the password before the first message is sent by klogin to the KDC. Therefore, without network sniffers to grab the KDC replies, an attacker cannot easily carry out a password-guessing attack. No KDC replies will be encrypted with the user's secret unless a password has been entered. Instead of entering just the principal name as in V4, the user must enter both the principal name and password before klogin sends the authentication request.

Numerous other improvements can be found including enhancements to the authenticators. Most of the criticisms identified previously are addressed in Kerberos Version 5. For example, the Kerberos V5 authenticator can be a complex data structure for a challenge-response dialog as recommended by Bellovin and Merritt (1992). Kerberos V5 also enables a client program to choose to which network address the ticket is bound, in cases in which the client program is running on hosts with multiple network adapters.

Two other interesting features of V5 tickets are the capabilities to perform ticket forwarding and delegation. A ticket is forwarded if it is obtained at one network address but is to be used by the principal at another network address. The ticket essentially can be passed between network nodes until it is consumed on the appropriate machine. Delegation is an option that allows a second principal to be able to use a ticket on the ticket owner's behalf. Principal X could obtain a ticket by authenticating to the KDC but request that the ticket be usable by principal Y instead. A number of other ticket qualifiers have been added such as predating a ticket so that it becomes valid on a future date.

One final component of Kerberos V5 deserves mention. Included with this release is a set of programming interfaces that vendors can exploit for application-level encryption.

The Generic Security Services API (GSSAPI) has been implemented on top of Kerberos V5 and relies on the DES algorithm for security. GSSAPI includes routines that a vendor can call for providing authenticity, privacy, and message integrity in communications. If a vendor's product is required to provide secure communications across insecure networks, GSSAPI interfaces are available to deliver the necessary security services. The implementation obviously would require the existence of a Kerberos V5 server to satisfy the calls made to the GSSAPI.


X.509

A digital certificate can be thought of as an electronic passport, which is uniquely used to identify entities in a network. Certificates are most commonly associated with system users, although a certificate could be created for software servers just as Kerberos creates principal secrets for these entities. The most common form of digital certificate is the one defined by the X.509 ISO standard. An entire suite of ISO standards is targeted at providing secure, distributed communications in a network. X.509, which is part of the X.500 series of standards, is concerned with the precise format of digital certificates.



This section describes how X.509 certificates provide for significant improvements in I&A for networked environments.

The Lure of X.509

A major benefit of certificates is that they are based on public-key technology. One of the problems with Kerberos is that the principals and the Kerberos server must share a secret key. No such requirement exists for the X.509 approach to authentication. Public-key cryptography takes advantage of the relationship between the public key and private key. Because the keys can be used for complementary cryptographic operations, entities in the network do not have to share a secret key to prove identity. An example will help clarify how this works.

Let Px be the public key of user X and Sx represent the secret key of the pair. To verify the identity of user X, Y chooses a random nonce N value and encrypts it with Px. Y then transmits {N}Px to X. To prove identity X decrypts {N}Px using Sx and transmits this value N back to Y. Only X who secretly knows the mathematical inverse key Sx for the public key Px could have successfully decrypted the challenge.

As a final twist, if two-way authentication is required, (Y can be challenged to prove knowledge of Sy in a similar fashion. To improve the protocol X could encrypt N with the public key of Y before sending the response. Even this change is not sufficient for a complete protocol, because an attacker between X and Y can still modify the messages in transit.

To see how public-key cryptography can be further utilized for establishing secure network communications, consider that the nonce value N can become the session key between X and Y. Not only is authentication of the entities accomplished, but they also now share a secret key for encrypting exchanged messages. Another consequence of the inverse relationship between the key pairs is that Y can ask X to digitally sign some message M with the secret key Sx. At a future time, it can be shown, by decrypting the digital signature {M}Sx with Px to obtain M, that only X could have provided the signature. To be precise, the digital signature is not computed as an encryption function as the notation {M}Sx implies. Rather, the signature is normally derived with a cryptographic hash algorithm.


Contents of an X.509 Certificate

The X.500 standard defines a naming syntax for a universal directory structure that can be used to store information about important entities in a network. An X.500 name consists of several attribute-value pairs. The syntax of a distinguished name uniquely identifying an entity, such as a user, would like something like the following: C=US, O=IBM, OU="Software Security", CN="John Doe"

Names of entities or objects are derived in a hierarchical fashion. Because the standards are international, different portions of the naming tree are assigned to various registration authorities who are responsible for further assigning subtrees to other authorities. In the example, the root of the naming tree is the attribute C representing the country. Other attributes are O for organization, OU for organizational unit, and CN for common name. Internally in a program, the representation of a distinguished name is much more complex, and like Kerberos V5, the naming is based on ASN.1 data types. For the purposes of this discussion, though, all you need to know is that each digital certificate is created for a particular entity identified by the distinguished name.

The certificate also includes the public key of its owner, an expiration value indicating when the certificate is no longer valid, a serial number, and other administrative fields. An important field appearing in the certificate is the digital signature of the Certificate Authority (CA) which issued the certificate. The signature could have been computed with any one of several cryptographic hash algorithms, so the certificate also includes information identifying which algorithm was chosen.


Certificate Authorities

Why are certificates issued by a CA? Although X.509 certificates simplify the process of distributing shared session keys and authenticating users, a trusted third-party authentication server is still needed for strict verification of identities. Certificates are designed to be public and published in a way that makes them easily accessible to other network entities. In some environments, the data store or directory used to publish certificates might be tightly controlled. Also, two users wanting to communicate over an insecure network may already trust each other and gladly exchange certificates without hesitation. However, in public networks, you should be concerned about whether a certificate is genuine. Products are readily available for creating X.509 certificates, and any user may be able to advertise a certificate claiming to be another party. Only by verifying the authenticity of the X.509 certificate can one be sure that impersonation is not a threat.

Various companies including IBM and Verisign currently offer CA services. The belief is that if a certificate is generated and signed by a respectable authority, users of the certificate can trust its authenticity. The CA generates the digital signature by using its secret key and then publishing its public key. The signature can be verified because of the relationship between the secret and public keys of the CA. The important points include the following:

1. X wanting to communicate with Y obtains Y's X.509 certificate.
2. X verifies the authenticity of the certificate by verifying digital signature of the CA that issued it.
3. When satisfied that the signature is legitimate, X can use the contents of Y's certificate to communicate securely.

You are not limited to having a single X.509 certificate. Indeed, you can obtain multiple certificates from different CAs and decide where to publish each one. If the secret key for a user is compromised in some way, the CA must revoke the corresponding certificates. Each CA must maintain a certificate revocation list (CRL). Before a certificate can be employed as the basis for secure communications, it should be compared to the CRL at the CA to verify validity. Creating a usable public key infrastructure, which includes providing CAs, is a major challenge facing many companies and governments today.


Why X.509 Is Popular

The X.500 family of standards has been around for quite some time. Still, not many software products used these standards until the explosion of interest in the Web. The Secure Sockets Layer (SSL) is widely relied upon for secure communications across the Web. A commonly used implementation of SSL is delivered by RSA, Inc., now part of Security Dynamics. The founders of RSA (Rivest, Shamir, and Adelman) were some of the original researchers in public-key technology. Consequently, it is not surprising that SSL is based upon public-key techniques and X.509 certificates. Web browsers and servers that carry out secure communications across the Internet primarily depend upon SSL for security services.

Like GSSAPI in Kerberos V5, SSL is available separately as a set of library routines from RSA. This means that arbitrary applications written by vendors can be enabled to take advantage of SSL features for secure distributed communications. Because the UNIX sockets interface is a common programming abstraction for thousands of programmers, you can reasonably assume that SSL will be a popular tool for distributed security in many products to come. Higher level programming interfaces, such as Microsoft's CryptoAPI and Intel's Common Data Security Architecture (CDSA), also fit nicely with the X.509 and SSL approaches.


Comments on X.509 Security

The weakest component in the X.509 approach is still the reusable password. If you have a Web browser that supports certificates, you already know that the certificates are stored on your system's disk. Before writing the certificate to disk the system first encrypts it using a password hash. The password is reusable and chosen by you when configuring your browser. For unattended operation of servers that rely on certificates, a data store is also needed for the server's secret key or keys. In this case, a password chosen by the system administrator is the basis for the hashed key used to encrypt the server's secret key. If an adversary can capture the encrypted value, an offline password cracking attack can be undertaken.

It is practically impossible to break commercially available public-key implementations, assuming sufficient key lengths and discarding experienced cryptanalysis. However, the system is still threatened because if the secret key of a key pair is disclosed, an attacker can impersonate the certificate's owner or decrypt private messages. Because the secret is protected by the fallible reusable password, we have sufficient reason for concern.

Note also that with respect to identity within the context of a local operating system, X.509 certificates are not replacements for UIDs and GIDs. Like Kerberos, X.500 and X.509 introduce their own subjects and objects, and even bring along a separate access control mechanism. It's not hard to find UNIX network applications that are enabled to work with Kerberos. Discovering a freely available or commercial version of one of these applications that has been modified to use X.509 is less likely today but should change in the near future. Given the widespread interest in certificate-based authentication, it is advisable for operating system vendors to support integrated login with X.509.

Some important concepts can be summarized from the previous discussions on authentication:

1. Authentication involves proving knowledge of a shared secret.
2. Reusable passwords are not the most reliable value for authenticating users.
3. A shared session key, regardless of how it is obtained, can be used for secure communications between parties. The session key can also be used to establish the authenticity of the parties.
4. A session key that is used only once is very desirable because it is highly resistant to cryptanalytic attacks.
5. An authentication server can be used to distribute shared secrets to parties, and such a server is an administrative necessity in large networks.
6. Frameworks such as Kerberos and X.509 do not replace the subjects and objects in an operating system, although they can be used to augment the I&A process.

Now that you understand some alternatives for secure authentication and communication, it's time to make some additional recommendations for improving login security at your site.

As you have seen from the previous discussions, traditional I&A security is weak in a number of ways. Intrusion detection products are designed to assist by monitoring the system for password attacks and other suspicious behaviors. Even if you have an authentication server such as Kerberos, RADIUS (Rigney et. al. 1997), or TACACS (Finseth 1993), you will want to add an IDS to monitor the authentication server. Weaknesses in Kerberos implementations or protocols (some identified earlier) as well as published exploits for RADIUS implementations should encourage you to monitor the activities of your authentication servers with an IDS. After all, I&A is the first step in securely accessing your system.


One-Time Passwords

The first improvement to I&A is to depend upon one-time passwords instead of reusable passwords. In practice, this approach requires the use of cryptography, although one can easily envision a simpler case. For example, two people could decide to sequentially use all words from an encyclopedia as the authenticating values for communicating. Each time authentication is needed, the originator sends the next word in the encyclopedia as the authenticator value. The recipient merely checks the value against another copy of this readily available code book if the authentication is unilateral. For bilateral authentication, the originator sends the next available encyclopedia word, and this word's successor is sent as a response by the recipient.

Several problems exist with the encyclopedia protocol as described. The universe of passwords is easily cracked if an adversary determines which volume of the encyclopedia is serving as the code book. Also, it is recommended that a more complex algorithm than the successor function be used to authenticate the recipient. For example, the second party in the conversation could begin choosing passwords for the return messages by working backwards from the last page of the encyclopedia. Of course, both parties would need to know this variation in the protocol.

Still another problem is that you must assume that the communication channel between the originator and the recipient is not secure. If an adversary can capture and modify the message in transit, authentication will not be reliable. Attempts by an attacker to replay a previously used password are not a threat because each password is unique and used only once.

The basic idea is that the two parties share a secret, or secrets, chosen from a predetermined universe of values. Each secret is used only for a single authentication. If a secret were to be reused, a number of confounding issues would be introduced, such as the need for an expiration time on a secret The strength of one-time passwords depends on the secrecy of the password generator and naturally on the secrecy of the storage device for the passwords. Cryptography is preferred when deriving or using one-time passwords because cryptography is more resistant to a variety of attacks.


Strong Authentication

Rather than transmitting the secret value itself, whether in unilateral or mutual (bilateral) authentication, strong authentication prescribes that an entity only prove knowledge of the secret. In other words, strong authentication involves demonstrating that you know a secret without actually revealing the secret. Obviously, login passwords are not a form of strong authentication because you must actually enter your password to authenticate to a system.

Imagine a modified UNIX I&A procedure in which you do not enter your usual password. When the system prompts you for the password, you provide a value that is derived from your password. For example, assume that your password is an integer or that the password can be converted into an integer value. In response to the password prompt, you multiply your integer password by a predetermined constant value, such as the integer 4, and key in the result. In this way, you are not revealing the secret you share with the system. Unfortunately, this simple approach is not much stronger than relying on reusable passwords because the example algorithm is too simple. Again, cryptographic techniques commonly underlie commercial implementations of strong authentication.


One-Time Passwords and One-Time Pads

The strongest cryptographic protection comes from using one-time pads. A onetime pad is a randomly generated string of characters to be used as the key for encrypting plaintext. For the moment, think of the plaintext and the one-time pad as binary strings. Encryption is accomplished by XORing the plaintext with the key. Each bit in the one-time pad key is used to encrypt a single bit in the plaintext, and each bit in the key is used exactly one time. Reusing any portion of the key reduces the strength of the cipher. Therefore, bits of the key are discarded after they are used. The accomplice receives the ciphertext and reverses the operation using the same one-time pad. Both parties must have agreed on the contents of the one-time pad in advance. Additionally, if either party loses synchronization with the other, the message will not be decrypted correctly.

Spies have long relied upon one-time pads, actual printed sheets with keys, to exchange small amounts of super-secret information. Unless the pad used to encrypt the message cannot be found, deciphering the message is computationally infeasible. Although no formal proof exists for guaranteeing that a cryptographic algorithm is unbreakable, intuitively the one-time pad is the most secure method because any string of 1s and 0s is an equally probable key. The search space is practically infinite.

Because the key length must be identical to the message length, one-time pads are impractical for general cryptographic communications. Also, the approach is only as safe as the technique used to generate the random numbers of the key. In practice, random-number generation has often been the weakest component in a security product. The random-number generator of an early Netscape product was cracked not long after Netscape offered a reward for doing so. For a thorough treatment of randomness in computing see Luby (1996).

A one-time password is similar to a one-time pad in that the password is used only once for authentication. After the user or other entity is authenticated, the password is discarded.


Two-Factor Authentication

Recall that authentication can be proven by demonstrating something you know, something you have, or something you are. Combining any two of these to form two-factor authentication markedly adds to the security of the authentication system. For example, if you must know a secret key sequence and if you are required to possess a badge to access a secured area, this method is better than relying on only one of the two values. The Security Dynamics Inc. (SDI) ACE/Server was one of the first commercial products to combine one-time passwords with token devices.


Security Dynamics ACE/Server

SDI provides a variety of token devices, the most familiar one in the form of a small electronic card. The token card displays an integer value to use as a one-time password. The value is not random but is instead computed as a mathematical function of the token's unique ID and the current time. The ACE/Server knows the unique ID of each token as well. Before a token is distributed to the user, its time and unique ID are synchronized with the ACE/Server. At any given instant in time, the token card and the ACE/Server are locked onto the same one-time password value. The details of the mathematical computation used to generate the unpredictable integer values are not public. Like most time-synchronized systems, some amount of clock skew can be tolerated by the communicating systems. The skew value is configurable in the ACE/Server for each token device registered in its database.

A software token device was designed to operate the same way as a physical card but overcomes previous complaints about cards such as cost. Some tokens require that the terminal support a token reader device. For example, a token could be combined with a physical key that must first be used to unlock the token reader. Only after this step is complete can the user proceed to use the token card for authentication.

The ACE/Server contains a database of users, in which each user is associated with a personal identifier number (PIN) and individual token card. The PIN can be chosen by the user, and thus hidden from the administrator, or it can be assigned by the ACE/Server depending on site policy. PINs can be composed of numbers only or both numbers and letters. The PIN length is an important security factor, and SDI recommends a minimum length of six. Notice that the ACE/Server has introduced another repository for storing user information. This database must be kept in sync with the /etc/passwd file, for example, if SecurID cards are being used to replace reusable password logins in UNIX.

To authenticate to the ACE/Server the user enters both the PIN and the current number displayed on the token device. Together these values are called the passcode. This type of authentication is much stronger than using a single value such as a password. What happens if an attacker manages to steal a PIN and somehow guess a token value, without possessing the token card? If the attacker tries several values before the guess succeeds, the ACE/Server detects the guessing attack and prompts for a second token value. Someone probably cannot guess two successive token values in sequence or the original token value in a single guess. The guessing threshold can be configured by the administrator. A separate threshold can be configured to limit the number of total failed passcodes allowed before a card is inactivated.

A stolen token card is useless without the user's PIN. If the ACE/Server detects a sequence of events consisting of repeated incorrect PIN guesses with the appropriate token value, the server assumes that the token card has been stolen and ignores future authentication requests from that card. Someone who steals a token card and also uncovers the user's PIN can impersonate the user. Because time synchronization between the server and the token cards is critical, the server will alert the administrator if its time is set back. A replay attack is possible with a previously used passcode if the server clock is set back. An adversary could shoulder surf to obtain an old token integer value. The PIN alone would be insufficient for a replay attack.


Attacks against ACE/Servers

Although SDI created a very strong authentication mechanism, successful attacks against the server have been documented. Two threats are faced by one-time password systems. The first problem is the man-in-the-middle attack in which an adversary sits on the network between the client and the authentication server. The attacker attempts to capture the packets for future replay or merely monitors packets in an effort to launch the second hack based on a race condition.

Because most authentication systems have defenses for replay attacks, the race condition is a greater threat. SecurID cards are configured to return or display a fixed-length value. This is true whether the token value is returned directly or the card is used for a challenge-response protocol. The default is 10-digit integers with no alphabetic characters. With enough effort, an attacker can discern the length for a given card that is the target of the hack. Early ACE/Servers were subject to the following weakness assuming that the length of the token value is D digits.

An opponent on system O first would detect that the login user has initiated an authentication session from the client to the ACE/Server. O then opens up D simultaneous authentication request connections with the server, too. The attacker watches each keystroke entered by the user as it is sent in a packet to the server. Assuming that the login user's system is not buffering the token value and sending it in a single packet, each digit of the integer will be sent in a separate packet. As a digit is seen in a packet from the client to the server, O similarly packages up that digit and sends it to the server in each of its D connections. After the second to last digit (D-1) is sent by O, one each of the digits 0-9 will be sent by O on each of the D connections. This represents an attempt by the attacker to guess the appropriate last digit and send it to the server before the client. Network jamming techniques could be employed for slowing packet delivery from the client, so the attacker has a strong possibility of beating the client to the server. In addition, the attacker now has a 1-in-D chance of successfully authenticating to the server. Note that if the guessing threshold is set low enough, the token card will be disabled.

SDI modified the ACE/Server to deter this type of attack. For example, a token card can be used only in a single authentication dialogue. The same token cannot be used in simultaneous login attempts, although the same card can be reused within a short, configurable time interval. This fix is reasonable because it is unlikely that the token card can be in two distinct physical locations at once. Also, because network traffic between the clients and ACE/Server are encrypted and digitally signed, this attack is more difficult to carry out.

Unfortunately, if a token card is subjected to the preceding attack, the user now is exposed to a denial-of-service problem. An adversary can attempt to launch login sessions shorter than the allowed interval. The ACE/Server will disable a token card if this is detected, even if the card's legitimate owner accounts for one of these login sessions.

Note that these attacks are really targeted at the protocol used between the client and the server. Although the SecurID card is backed by some expert security designers, it is inherently difficult to devise secure, distributed authentication protocols. Other protocol exploits can be found in the paper securid.ps found at www.secnet.com. Note that many of these problems have been fixed since the paper identified them. Still, it is interesting to read how complicated it can be to safely deploy strong authentication systems. As noted in the introductory chapters, a product will help you solve one class of problems, but by adding new protocols and security models, it also might open your system to attacks not previously possible.


Challenge-Response Authentication

To strengthen I&A further, the authenticating system displays a randomly chosen integer each time it shows the password prompt. Instead of merely keying in your password, you calculate some mathematical function using this challenge value and respond with the computed result. If the mathematical function used is cryptographically strong, you significantly improve I&A beyond the reusable password method. NT uses a challenge-response technique for authentication with domain controllers, although this authentication is not based on two separate factors by default.

Some commercial products, such as Digital Pathways (now part of Axent) combine challenge-response with hand-held token devices. The authentication software chooses a random value and sends it to the user as a challenge. A shared secret between the authentication server and the user is stored inside the token. The user keys the challenge into the token device that computes the response. To authenticate to the server, the user enters the response, which is verified at the authentication server.

You want to avoid some potholes with challenge-response systems. The challenge should come from a random source. Timestamps do not make good challenges because they come from a predictable sequence of numbers. Also, if the time values are not fine grained, you may be able to replay previous values or to trick one of the parties into computing responses in advance, which could be later used for a reflection attack. Finally, if authentication is mutual, each side of the protocol should use a different challenge, each preferably from different domains-such as the initiator always sends an even number, and the responder sends an odd number.


The Need for Intrusion Detection

Your environment requires different software and hardware tools for solving security problems. Even as you add new techniques for reducing risks, you will find that enhancements you deploy also have their own weaknesses-either in implementation or in the way they might be configured. Therefore, you want to add IDS tools to detect and respond when other tools in your environment don't work perfectly.

The two key recommendations for improving I&A security are to user either one-time passwords or strong two-factor authentication with token devices as a replacement for reusable passwords. Although the cost of deployment might be more, the added security is well worth the expense.

Finally, even though more secure authentication products, such as the Security Dynamics ACE/Server, can be added to your site, avenues of attack will still be open for a hacker. Some examples of attacks against the ACE/Server were described to emphasize this point. An authentication product will not deter, prevent, or detect many attacks. For example, an I&A product will not detect someone who maliciously deletes files or otherwise violates your security policy once logged in to the system! If you want to catch intruders who have hacked through your I&A system or insiders who are misusing corporate resources, IDSs are needed to detect and respond. Also, because systems like Kerberos introduce additional security models, you want to monitor their activities for intrusive behavior such as password guessing attacks.


Biometrics

Space does not permit a thorough coverage of the explosive field of biometrics. It seems that a new biometric product alliance is announced every day. A few years ago security product vendors rushed to alter their products to work with authentication devices from Security Dynamics or Digital Pathways. The same now can be said of biometric authentication. I&A systems based on fingerprints, voice, facial features, and keystroke patterns are available today.


Author note: This security paper is to be used as a reference tool only, and may be distributed freely. The information provided was researched by implementing various sources.

E-Mail Link

Your IP address will be sent with this e-mail

From e-mail to e-mail