Authentication

Before authorization may occur, for anything other than anonymous access to wholly public resources, the identity of the account attempting to access a resource must first be determined. This process is known as authentication . The most well known form of authentication is the use of a logon account identifier and password combination to access controlled resources. Access is not possible without both required account authentication parts , thus a level of protection is provided.

The shortcoming of any authentication system is that keys used may be easily falsified. This can lead to access rights being granted to an unauthorized access attempt. Null or easily guessed passwords are among the most widespread examples of the potential for this weakness.

The relative strength of an authentication system involves the difficulty associated with falsifying or circumventing its process. Anonymous or open access represents the weakest possible form of authentication, whereas the requirement for both a logon identifier and password combination may be considered the most basic of actual account verification. Beyond this, authentication may involve restricting access only when occurring from specific network addresses, or if an identified digital key or security token, such as an access smartcard , is present.

In theory, the strongest security would be offered by identifying biometric keys that are unique to a particular user 's person or physical body, such as fingerprints and retinal or iris patterns, combined with other authentication methods , such as access passwords or token-based security that requires the possession of a physical smartcard key.

Obviously, the needs for authentication are going to be relative to the value assigned to a particular resource's security. Adding more layers of authentication increases both the administrative overhead required for management and the difficulty users will have gaining access to needed resources. As an example, consider the differences in authentication requirements for access to a high-security solution such as the Federal Reserve's banking network, as opposed to those needed to access an unprivileged local account in a public kiosk.

Obviously, in the first scenario, to establish authentication for rightful access, the use of a combination of biometric, token-based, and password-form access methods may be mandatory. You may also use these access methods with even more complex forms of authentication, such as the use of dedicated lines of communication, time-of day restrictions, synchronized shifting-key hardware encryption devices, and redundant- path comparisons. You would use these to ensure that each account attempting to make a transaction is properly identified. In the second scenario, authentication might be as simple as an automatic anonymous guest logon shared by all visitors .

In the following section, we discuss the various methods of authentication. These include Kerberos, which uses tickets; Challenge Handshake Authentication Protocol (CHAP), which uses a challenge/response mechanism; certificates, which use encryption; tokens, which are hardware devices; and biometrics, which combines each individual's unique traits with technology.

Kerberos Authentication

The most basic aspects of authentication, within a completely isolated network, would only include the need to determine the identity of an account. If a network is itself physically or logically accessible to external parties that might seek to sniff (that is, capture and examine) data being transmitted between systems, the problem arises as to how to keep the authentication keys themselves safe.

Here is an example. A basic File Transfer Protocol (FTP) access session involves the client sending a logon identifier and a password to the FTP server, which accepts or rejects this access. The logon identifier and password, by default, are sent in plaintext form, readable by any agent with access to the data as it is transmitted from the client to the server. This information could then be used later to allow an unauthorized party to access the server, pretending to be the authorized user.

To avoid the process of sending the actual logon information across an unsecured network, a solution created by the Athena project at MIT can be usedthe symmetric-key authentication protocol known as Kerberos . The term symmetric key means that both the client and server must agree to use a single key in both the encryption and decryption processes (see Figure 2.1).

Figure 2.1. Example of a symmetric-key encrypted data transfer.

In Kerberos authentication, a client sends its authentication details not to the target server but rather to a Key Distribution Center (KDC) through the following process:

1. The Authentication Service (AS) receives the client request and verifies the user ID and request in a database.

2. Once the request has been verified , a timestamped session key is created with a limited duration (by default, eight hours) using the client's key, as well as a randomly generated key that includes the identification of the target service.

3. This information is sent back to the client in the form of a ticket-granting ticket (TGT).

4. The client then submits the TGT to a ticket-granting server (TGS).

5. This server then generates a timestamped key encrypted with the service's key and returns both to the client.

6. The client then uses its key to decrypt its ticket, contacts the server, and offers the encrypted ticket to the service.

7. The service uses its key to decrypt the ticket and verify that the timestamps match and the ticket remains valid.

8. The service contacts the KDC and receives a timestamped session-keyed ticket, which it returns to the client.

9. The client then decrypts the keyed ticket using its key. After both agree that the other is the proper account and that the keys are within their valid lifetime, communication occurs.

The short lifespan of a ticket ensures that if someone attempts to intercept the encrypted data to try to break its key, the key will have changed before that person can break the key using cryptographic algorithms. The handshaking between the client and the KDC, and the service and the KDC, provides verification that the current session is valid without requiring the transmission of logon or password information between client and service.

The strengths of Kerberos authentication come from its time-synchronized connections and the use of registered client and service keys within the KDC. These circumstances also create some drawbacks, such as the need to use a standard time base for all systems involved as well as the difficulties that can result if the KDC is unavailable or the cached client and service credentials were accessed directly from the granting servers.

Mutual Authentication

Kerberos v.5 includes support for a process known as mutual authentication , in which both client and server verify that the computer with which they are communicating is the proper system. This process helps to prevent man-in-the-middle attacks, where an unauthorized party intercepts communications between two systems and pretends to be each to the other, passing some data intact, modifying other data, or inserting entirely new sets of values to accomplish the desired tasks . (See Chapter 3 for more on man-in-the-middle attacks.)

In mutual authentication, one system creates a challenge code based on a random number and then sends this code to the other system. The receiving system generates a response code using the original challenge code and also creates a challenge code of its own, sending both back to the originating system. The originating system verifies the response code as a value and returns its own response code to the second system, generated from the challenge code returned with the first response code. Once the second system has verified its returned response code, it notifies the originating system, and both systems consider themselves mutually authenticated.

Challenge Handshake Authentication Protocol (CHAP)

The Challenge Handshake Authentication Protocol (CHAP) can be used to provide on-demand authentication within an ongoing data transmission. CHAP uses a one-way hashing function that first involves a service requesting a CHAP response from the client. The client creates a hashed value that is derived using the Message Digest (MD5) hashing algorithm and sends this value to the service, which also calculates the expected value itself. The server, referred to as the authenticator , compares these two values. If they match, the transmission continues. This process is repeated at random intervals during a session of data transaction.

Several items are worth reviewing from the previous paragraph. The CHAP process is repeated at random intervals during the session. This helps eliminate the possibility of a replay attack. The process of authenticating is called a three-way process . Actually, four steps are involved because the first step is establishing the connection, but the authentication process itself is a three-way process.

Remember that CHAP functions over Point-to-Point Protocol (PPP) connections. Also, you should be able to recognize the two forms of CHAP that are Microsoft specific: MS-CHAP and MS-CHAPv2.

Certificates

One of the most rigorous forms of authentication involves the use of digital certificates within a Public Key Infrastructure (PKI). These certificates are used to establish encrypted communication streams through unsecured networks. Public key systems utilize an asymmetric cryptographic process in which the encryption and decryption keys are not the same, as opposed to a symmetric cryptographic process like that used in Kerberos authentication.

PKI is the basis for many commonly encountered data encryption solutions, including the use of the X.509-compliant keys used in establishing Secure Sockets Layer (SSL) connections most often seen in secured Web site forms (HTTPS on port 443). PKI is discussed in detail in Chapter 8, "Basics of Cryptography."

In public key encryption, a public key and private key are generated by a Certificate Authority (CA), and these keys are returned to the client in the form of digital certificates. The public key is given to those who need to encrypt data and send it to the client. The client then decrypts the data using its private key, which only the client has. The public key is used to encrypt a message, and the public key is used to decrypt the results. So, if you send Diane a message, you can find out her public key from a central authority and encrypt a message to her using that public key. When she receives it, she decrypts it with her private key. Besides encrypting messages, she can also authenticate herself to you by using her private key to encrypt a digital certificate. When you receive it, you then use her public key to decrypt it. The purpose of encrypting messages is to ensure privacy. The purpose of encrypting signatures is to validate the identity of the person who sent the message.

To send an encrypted message, the receiver's public key (the security key open to anybody who can be found from a central authority) is used. To decrypt a message, the receiver's private key (the security key only known by the recipient) is used. If you want to send a message using an encrypted signature, the sender uses his private key. To decrypt an encrypted signature, the sender's public key is used.

A Registration Authority (RA) provides authentication to the Certificate Authority of the validity of a client's certificate request. One of the most commonly used Certificate and Registration Authorities is VeriSign, a vendor specializing in the issuance of X.509 certificates for secure Web site connections.

Username and Password

The most common form of authentication is the combination of a username and a password or passphrase. If both match values stored within a locally stored table, the user is authenticated for a connection. Password strength is a measure of the difficulty involved in guessing or breaking the password through cryptographic techniques or library-based automated testing of alternate values.

A weak password might be very short or only use alphanumeric characters , making decryption simple. A weak password can also be one that is easily guessed by someone profiling the user, such as a birthday, nickname, address, name of a pet or relative, or a common word such as God, love, money , or password .

Stronger passwords can be derived from events or things the user knows . For example, let's say the password requirements are that the length be nine characters and a combination of letters , numbers , and special characters must be used. So, let's say a user is going to the Bahamas on June 6, 2003, with his spouse, Judy. The phrase "Going to the Bahamas on June 6, 2003 with Judy" can become gtB6603@J. The user now has a complex password that is easy to remember!

Tokens

One of the best methods of authentication involves the use of a token , which may either be a physical device or a one-time password issued to the user. Tokens include solutions such as the chip-integrated smartcard or a digital token such as RSA Security's SecurID token. Without the proper token, access is denied . Because the token is unique and only granted to the user, it is harder to pretend to be (spoof) the properly authorized user. Digital tokens are typically only used one time; therefore, they cannot be captured and reused later by an unauthorized party.

Biometrics

Obviously, the most unique quality of a user is his body and its unique physical characteristics, such a fingerprints, retinal patterns, iris patterns, facial blood-vessel patterns, bone structure, and other forms of specific, unique biophysical qualities. Other values may be used, such as voice patterns or high-resolution cardiac patterns, but because of the manner in which these may change due to illness or exertion, they can be somewhat less dependable.

New systems are becoming available to allow authentication of a user by her body's measurements (biometrics), which are compared to values stored within a local table to provide authentication only if the biometric values match. Another alternative includes storing biometric data on smartcard tokens, so a user must have both to be authenticated within a widely distributed scheme, where transactions against a central server storing large and complex biometric values might be difficult.

Multifactor

The best possible authentication solution involves a combination of other methods. A multifactor solution like this might include the use of a smartcard token storing biometric values that are compared to those of the user, who might also be asked to enter a valid password. In other words, multifactor authentication combines something you have with something you know. The difficulty involved in gaining unauthorized access increases as more types of authentication are used, although the difficulty for users wishing to authenticate themselves is also increased similarly. The administrative overhead and cost of support also increase with the complexity of the authentication scheme, so a solution should be reasonable based on the sensitivity of data being secured.