Lesson 1: Understanding Authentication | Security+ Certification Training Kit (Pro-Certification)

Lesson 1: Understanding Authentication

For the security specialist of a company, authenticating users is a significant challenge. For example, you might have to manage multiple users accessing resources from the same computer, or users accessing networked resources. Every time a user gains access to your company's computers, network, or resources, you must ensure that the user is permitted to access those resources. To do this, you must incorporate an authentication method into the process of providing access to resources.

After this lesson, you will be able to

Describe different types of authentication
Describe Kerberos authentication
Discuss implications of combining authentication methods

Estimated lesson time: 35 minutes

Authentication requires a user to provide some proof or credential that represents something they know, something they have, or something they are before allowing access to your company's resources. Examples of each of these categories include the following:

Something you know.
A password or personal identification number (PIN)
Something you have.
A smart card or other physical object
Something you are.
A thumbprint or other biometrics

The authentication process can be a one-way process, where only the user's credentials are authenticated, or a mutual authentication process, in which both the user and the resource authenticate to each other. To require strong authentication, you must understand what authentication methods are available, their strengths and weaknesses, and how to combine those methods to provide strong authentication.

User Name and Password Authentication

User name and password authentication are common methods used to validate that people are who they say they are. With this, a user is typically presented with a dialog box and must provide his or her user name and password. The user name is typically visible on the screen and is handled as cleartext, whereas the password is typically masked on the screen and is encrypted.

If the authentication is performed locally, for instance when a user logs on to a stand-alone computer, there could be a process running that intercepts or records the user name and password. This could provide a hacker with the information needed to gain access to a single computer or your entire network.
If the authentication process is centralized, for instance when a user logs on to a network, then the user name and password are sent to a different computer that is responsible for authenticating users and providing them credentials that can be used to access networked resources available on that network.

When possible, you should require the user to have a user name and complex password rather than a simple password, and it should be enforced by the operating system or network operating system in use. Examples of a simple password include a person's first name, last name, birthday, phone number, or a common word. Although these might appear to be difficult to guess, using today's computing technology, they can be broken quickly. As described in Chapter 4, a complex password includes uppercase, lowercase, and numeric characters, symbols, and punctuation. Even when numbers are used to replace letters, there are modified dictionary password-cracking programs available that can replace standard characters with common symbols and numbers and then run against a password. For example, if you want to use a password like football and choose footba11, a password-cracking program may quickly decipher your password because it involves a simple replacement. However, the password Pho0tB@!1 is much more difficult for a password-cracking program to decipher.

Because example passwords are often added to password-cracking programs, you should not use any passwords you see printed in this or any other publication.

Although you can force a user to set a difficult password and require the user to memorize the password (as opposed to writing it down), the user might feel the password is too difficult to remember and will write it down on a piece of paper located near his or her desk or under the keyboard. Some best practices to enforce with passwords include the following:

Force the users to have passwords that include uppercase and lowercase letters, symbols, and punctuation. Do not allow passwords that are all alphabetic or numeric characters.
Force the users to change passwords every 30 to 42 days. If it appears that a password has been compromised, force the user to change the password immediately. For example, if a single user account is used to log on to multiple workstations simultaneously or within a short time interval, you might suspect that the account is compromised. Other potential indications that a user account is compromised include logons at unusual hours, attempts to access restricted resources, and multiple connections to resources that a user would not typically utilize.
Do not allow users to use the same password again. If available, enable the histories function for passwords and do not allow the user to use the same password for at least five times. The longer the history the better. This, in concert with not allowing the user to change passwords too often, deters a user from quickly cycling through passwords to use the same one.
Create a policy that does not allow users to write their passwords down. This is a written policy and cannot be enforced programmatically, but, if tied to disciplinary actions, it can deter users from recording their passwords.
Create a policy that does not allow users to share their passwords with anyone, including help desk personnel. This policy cannot be enforced programmatically, but, if tied to disciplinary actions, it can also deter users.
Provide user education on social engineering (discussed in Chapter 11, "Incident Detection and Response"), strong password creation, and the network security breaches that can occur if written policies are not followed.
Create and follow well-defined policies for verifying the identity of a user before resetting his or her password. To prevent a hacker from pretending to be a user and getting the password reset to attack the network with the user's account, use a process to validate the identity of the user. For example, you might call the user's manager to verify the request before changing the password.

Kerberos Authentication

Kerberos is a network authentication protocol that provides strong authentication for client/server applications by using symmetric key cryptography. Kerberos is designed to provide a single sign-on to a heterogeneous environment. Because most operating systems are capable of communicating across a network and support Kerberos authentication, and Kerberos is scalable enough to operate on the Internet, it can be used as an authentication mechanism on the Internet and in other heterogeneous environments. Kerberos allows mutual authentication and encrypted communication between users and services; therefore, it can be used over public communications mediums.

The Kerberos authentication process is more stringent than using a user name and password for authentication. When a user signs onto the local operating system, a local agent (process) sends an authentication request to the Kerberos server. The server responds by sending the encrypted credentials for the user attempting to sign onto the system. The local agent then tries to decrypt the credentials using the user-supplied password. If the correct password has been supplied, the user is validated and given authentication tickets, which allow the user to access other Kerberos-authenticated services. In addition to the tickets, the user is also given a set of cipher keys that can be used to encrypt all data sessions. The following are some definitions that are used in subsequent explanations:

Realm.
An organizational boundary that is formed to provide authentication boundaries. Each realm has an authentication server (AS) and a ticket-granting server (TGS). Together the AS and TGS form a Key Distribution Center (KDC). All services and users in the realm receive tickets from the TGS and are authenticated with the AS. This provides a single source of authority to register and authenticate with. Realms can trust one another, providing the capability to scale Kerberos authentication.
Authentication server (AS).
In a Kerberos realm, the AS is the server that registers all valid users (clients) and services in the realm. The AS provides each client a ticket-granting ticket (TGT) that is used to request a ticket from a TGS.
Ticket-granting server (TGS).
To minimize the workload of the AS in a Kerberos realm, the TGS grants the session tickets used by clients to start a session with a service. The client must use the TGT issued by the AS to request a session ticket from a TGS.
Cross-realm authentication.
Cross-realm authentication is the capability of users in one realm to be authenticated and access services in another realm. This is accomplished by the user's realm registering a remote ticket-granting server (RTGS) on the realm of the service. Rather than having each realm authenticate with each other, cross-realm authentication can be configured in a hierarchical fashion. This eases authentication for the AS and TGS, but might force the client to contact several RTGSs to access a service.
Remote ticket-granting server (RTGS).
An RTGS performs the same tasks as a TGS, but for a remote realm (a realm the user is not associated with). To do this, the TGS in the realm the user is in must register with the TGS of the realm of the service the user is accessing (the RTGS).
Ticket.
A ticket is a block of data that allows users to prove their identity to a service. Each ticket is stored in a ticket cache on the user's local computer and is time stamped, so after a given amount of time (typically 10 hours), the ticket expires and is no longer valid. Limiting the length of time a ticket is valid reduces the chances of a hacker obtaining a ticket and being able to use it for unauthorized access.
Ticket cache.
A ticket cache is a portion of memory that stores all of a user's Kerberos tickets. This cache is separate from the cache of the application that is using the ticket. With the tickets in their own cache, users need only provide their credentials once per session, even if several applications are using that ticket to access a service.
Ticket-granting ticket (TGT).
A TGT is a ticket that is granted as part of the Kerberos authentication process and is stored in the ticket cache. The TGT is used to obtain other tickets that are specific to a service. For instance, if a user wanted to gain access to a specific service, his or her TGT would be used in a negotiation process to get the additional ticket. Each service requires its own ticket.
Authenticators.
A series of bits, a symbol, or a group of symbols that are inserted into a transmission or message in a predetermined manner and are then used for validation. Authenticators are typically valid for five minutes. This is similar to the use of a cookie for being authenticated on a Web site. An authenticator can only be used once. This help prevents someone from intercepting an authenticator and then reusing it.
Principal.
A principal is any unique entity to which Kerberos can assign tickets.

Because Kerberos is a single sign-on environment, the tickets issued by the Kerberos server provide the credentials required to access additional network resources. This means that although the user is still required to remember his or her password, he or she only needs one password to access all systems on the network to which he or she has been granted access.

In addition to using Kerberos for authentication, it is possible to configure Kerberos to encrypt, thereby ensuring communication between authenticated hosts. Kerberos is implemented by a KDC, which contains the information that allows Kerberos clients to authenticate. The information is contained in a database that makes single sign-on possible. The KDC's database does not work in the same manner as many other databases.

In Kerberos, all network information (data about users, services, and hosts) is stored in the Kerberos database. This database contains the public keys of all principles. Any sensitive information, such as passwords, always stays on the KDC and the client. The KDC and the client establish trust relationships using public key cryptography. The trust relationship allows the KDC to then determine exactly which services a host and user can access.

Figures 7-1 and 7-2 show a simplified view of the Kerberos authentication process. As shown in figure 7-1,

When the user logs on to a system, the client (user) sends a registration request to an AS.
The AS authenticates the client and provides the client with a TGT, which is valid for a fixed amount of time.

figure 7-1 kerberos authentication process in the same realm

Figure 7-1. Kerberos authentication process in the same realm

When accessing services in the same realm (Figure 7-1), the following takes place:

The client contacts a TGS and requests a session ticket to access the service using its TGT.
The client then accesses the service using the ticket the TGS provided.

figure 7-2 kerberos authentication process in a different realm

Figure 7-2. Kerberos authentication process in a different realm

When accessing services in a different realm (Figure 7-2), the following takes place:

The client contacts a TGS and requests a TGT for the remote realm.
The client contacts the RTGS and requests a session ticket to access the remote service. The client uses the remote TGT to request a session ticket to access the remote service.

The client computer clock and clocks on the other servers must be somewhat accurate. The tickets that are granted are only valid for a certain amount of time, so if the clocks on the various computers are off by too much, the client tickets might not be able to be validated.

When a Kerberos client first obtains a ticket from the KDC, the token does not provide access to any particular process or network service. It is simply a token that informs other hosts that the KDC has authenticated this host, so this host and user can request services from other hosts. If the ticket and password match, then a session key is established and a credential cache is created. After the credential cache file is populated with the ticket, the host and user can use it to actually log on to hosts and request services. However, the service or host name must be contained in the Kerberos database, or access is denied.

Mutual Authentication

The term mutual authentication refers to the need for both the recipient and provider of a service to authenticate themselves to each other. Mutual authentication must be completed before the service can be provided. This assures the service that the user is who he or she claims to be and assures the user that he or she is connecting to the expected service. Kerberos allows a service to authenticate a recipient so that access to the service is protected. It also allows a service recipient to authenticate the service provider so that there is protection against rogue services.

In addition to a server authenticating a user and a user authenticating a client, there is the mutual authentication option of a client and a server trusting a third party, such as a certificate authority.

Certificates

Certificates provide the third-party trust in a mutual authentication scheme. A certificate is simply a block of data containing information used to identify a user. Information in the certificate includes the user's public key, information about the user, dates for which the certificate is valid, information about the issuer of a certificate, and a signature generated by the certificate issuer.

A signature can be generated using a private key over a block of data to produce another block of data known as the signature. The generator of this signature using the private key is referred to as the signer. This signature can only be decrypted using the public key of the signer, thus providing assurance in the identity of the signer.

A certificate is signed by a third-party certification authority (CA) so that if that CA says that the associated public key in the certificate is yours, any service you request can be assured that the public key is indeed yours and not from a hacker.

Certificates are typically requested from a certificate server at the site of a CA. To request a certificate, you send a certificate signing request (CSR) to the CA's certificate server, along with some other information to identify yourself. The information required is determined by the CA, and it varies from CA to CA. The CA staff then processes your CSR and generates a public and private key pair for you if they grant your request. They will most likely send you a public key over e-mail, but they should require that you retrieve your private key from them using some secure means, such as a secure Web connection download.

Remote Authentication with CHAP

Challenge Handshake Authentication Protocol (CHAP) is a protocol that can be used when a remote client needs to authenticate itself to a network server or when two routers need to authenticate themselves to each other to begin a Point-to-Point Protocol (PPP) session. CHAP avoids transmission of the actual password on the established connection. The authentication process used by CHAP involves a three-way handshake in which the network access server (NAS) sends a challenge to the client consisting of the session ID and a random string of data to the remote client.

The remote client uses a Message Digest 5 (MD5) function hash to return the following information:

The user name
An encrypted challenge
A session ID
A password

As discussed in Chapter 3, MD5 takes the variable-length string of data (the information just listed), and produces a 128-bit message digest that is used for validation.

CHAP protects against replay attacks by using an arbitrary challenge string for each authentication attempt and protects against remote client impersonation by sending repeated challenges at unpredictable intervals to the remote client throughout the duration of the connection.

Tokens

A token is a device that can be issued to a user for use in the authentication process. For example, there are token devices that, when enabled, synchronize with a server. Each minute the numbers in the server and on the device change to a predetermined number, as long as the battery in the device is working. For a user to authenticate, he or she must type in the number on the display, which must match the number in the server for the user to be authenticated.

Tokens are often small handheld devices, with or without keypads, that can range in size from a credit card to a small pocket calculator. Among other forms, they can be smart cards with small computer chips in them, requiring a reader when used with a PC. One type of authentication process used with hardware tokens involves a challenge-response process:

Enter your user name at a workstation and send it to the authentication server.
The server responds with a challenge to the token.
You reply using the token (or information provided by the token).
The server validates the information you provided and authenticates you.

Tokens are difficult to duplicate and are generally tamper resistant. Some can be carried with you for use on any workstation, although others require appropriate hardware peripherals and software on a workstation. Although tokens offer reliable security, they can be costly and difficult to deploy in an enterprise environment.

Tokens can either provide a one-time-use password or store information about the user. The user information can be a certificate and a password, as with smart cards. Smart card technologies provide strong security through encryption as well as access control. Smart cards require a reader that is used when the authentication is required.

Biometrics

Biometric authentication is an automated method of identifying a person based on a physical characteristic, such as a thumbprint or the retina of his or her eye. Using this type of authentication requires comparing a registered sample against a new captured biometric sample, for example, a fingerprint captured during a logon. The biometric authentication mechanism typically has two modes, enrolling and verifying.

Enrolling

For initial use of the biometric, a system administrator must enroll each user to verify that each individual being enrolled is authorized. The enrolling process includes storing the user's biological feature that will be used later to verify the user's identity. This is typically acquired by using a sensor (hardware device) that can record the particular feature, such as a thumbprint scanner.

Verifying

For the verification process, the user has a sensor on his or her computer that can capture the same biological information that was used for enrollment and then transmit that information to the authenticating server. The server can then compare the information presented by the user with the stored information to validate the user.

Some considerations when selecting a biometric authentication method include the following:

Performance and reliability.
This is not how fast the biometric device can perform the scan, but how well it performs the authentication process. Although device manufacturers provide information on the performance of their devices, the number of people used for the test and the assumptions for what environment the sensor will be used in vary. Reliability is typically determined by calculating the crossover error rate (CER), which is the point at which the false rejection rate (FRR) and false acceptance rate (FAR) are equal. The lower the CER the better. The FRR represents the percentage of authorized users who are incorrectly rejected, also called type 1 errors. The FAR represents the percentage of unauthorized users who are incorrectly identified as valid users, also called type 2 errors.
Difficulty.
User education should be a consideration when selecting a biometric authentication device. If the device is too difficult to use, the user might have trouble using it for authentication. Also, it can easily take a user a few weeks to adjust to using the device, and during that time the FRR rate will be higher.
User capability.
Some users might have an impairment that will not allow them to use a particular biometric device for authentication. You must provide a device that can be used by the majority of your users, and then provide an alternative device or authentication mechanism for those who cannot use the primary method.
Acceptance.
You users might consider some devices too invasive. Select a solution that will be palatable to your users, preferably a noninvasive biometric with continuous authentication, such as iris recognition.
Cost.
Some biometrics cost more to implement due to their complexity. Additionally, the cost of the individual scanning devices can vary greatly. For example, fingerprint-scanning devices are relatively inexpensive compared to iris scanning devices.

You'll learn more about how biometric technology operates in Chapter 9, "Operational Security."

Combining Authentication Methods

To make authentication stronger, you can combine methods, often referred to as multifactor or strong authentication. The most common type is two-factor authentication, such as using a PIN code and a SecurID token to log on to your network. A good example of two-factor authentication with which you are probably familiar is an automatic teller machine (ATM) card for getting money out of a bank. You insert your card (something you have) into the ATM and enter your PIN (something you know) to access your account number and perform transactions.

Combining more than one authentication method greatly increases the difficulty a hacker will have overcoming your security. For instance, if you require only a user name and password, a hacker might be able to programmatically "guess" the correct password. If only a smart card is used and the card is lost or stolen, a hacker would be able to use that card for access.

Individually, any one of these approaches has its limitations. Something you have can be stolen, whereas something you know can be guessed, shared, or forgotten. Although something you are can be considered the strongest approach, hackers are able to spoof that information as well, and it can be costly to implement.

Some general areas of concern you should consider when determining what authentication methods you will implement include the following:

Risk analysis.
Ensure that you know what the data that you are protecting is worth, what cost associated with the loss of the data will be, and what the chances are that the data will be compromised.
Solution evaluation.
Make sure that before you purchase and implement an authentication solution, you evaluate the products you are considering to determine their ease of use, cost, reliability, integrity, and capabilities.
Resources.
Consider the budget you have to perform the initial implementation and user education, as well as the continued costs of support.
Integration.
Ensure that the solution you propose will work in your existing environment and can be supported with the current staff you have available.
Ability to customize.
The products available might not solve the business problems and technical difficulties you face. Ensure that the solution you are implementing can be customized to suit your environment.
Cost.
The cost of implementing the solution is only part of the total cost. Make sure to consider the additional costs of training your users and performing ongoing maintenance for the methods you are proposing.
Performance.
Make sure the performance meets your expectations or that you realign the expectations of your users to match the performance your solution can deliver.
Accuracy.
Ensure that the authentication solution you propose can be used to accurately authenticate authorized users. Although manufacturers provide CER, FAR, and FRR information, you might have differing results in your environment.
Reliability.
Make sure that the solution you are proposing will operate for a reasonable amount of time in your environment. For instance, if the environment you work in is dirty, a thumbprint sensor might not be the best solution.
Maintainability.
Before selecting a solution, determine what is required to maintain the solution. This includes product costs and the amount of time it takes to perform the maintenance.
Availability.
Ensure that the solution you are implementing is available commercially. If the product is not fully developed or widely available, it might be harder and more costly to maintain your solution.
Upgradability.
Technology changes quickly. Make sure the solution you implement can be upgraded as technology changes.
Interoperability.
Make sure the authentication solution you provide is able to interoperate in your environment, and be aware of any environments in which the solution might not work.
Manufacturer reputation.
Verify that the manufacturer is reputable and stands behind its product. Verify that the manufacturer will provide support after you purchase its products.

Most authentication systems employ cryptography; therefore a cryptographic key management system will be necessary. The vendor you purchase your solution from might provide the key management component, but the process of maintaining and distributing keys will most likely require that you maintain that system.

Because the security of a cryptographic system is directly related to the level of protection provided for the cryptographic keys, it is essential for you and the vendor to develop a system for managing these keys effectively. The host computer system will probably evolve over time through the addition of new software and hardware, and these changes might require corresponding modifications or upgrades to the authentication system to maintain compatibility.

Exercise 1: Following a Cross-Realm Authentication

In this exercise, place the steps in order as they would occur in the following scenario.

Scenario: You are a user who has authenticated in one realm and you wish to access a service registered in another realm.

The client contacts the RTGS and requests a session ticket to access the remote service.
The client contacts a TGS and requests a TGT for the remote realm.
The client accesses the service.
The AS authenticates the client and provides the client with a TGT.
The client (user) sends a registration request to an AS.

Exercise 2: Reviewing Kerberos Terminology

In this exercise, match the terms in the left column with the correct definitions in the right column.

Realm
Authentication server (AS)
Ticket-granting ticket (TGT)
Ticket-granting service (TGS)
Kerberos Distribution Center (KDC)

What a AS and TGS form together
The ticket a client receives that allows them to request session tickets
The service that a client requests a session ticket from
The service that registers a client and provides them with a TGT
The logical boundary that is formed by an AS and TGS

Lesson Review

What type of authentication does Kerberos provide?
1. One-way authentication
2. Mutual authentication
3. Direct authentication
4. Indirect authentication
With CHAP authentication, what information does a client return in response to a challenge? (Select all that apply)
1. Session ID
2. Random string of data
3. User name
4. Encrypted challenge
5. Password
Select the answer that best describes token authentication:
1. Something you have
2. Something you know
3. Something you are
Select the answer that best describes user name and password authentication:
1. Something you have
2. Something you know
3. Something you are
Select the answer that best describes biometric authentication:
1. Something you have
2. Something you know
3. Something you are

Lesson Summary

Kerberos provides a method of mutual authentication that is scalable enough to support authentication across the Internet.
A Kerberos realm is a boundary that is comprised of an AS and TGS. Together these form a KDC.
Once a principal in a realm is granted a TGT, it is able to obtain session tickets for other realm principals.
To access services in other realms, the TGS in each realm must form a relationship. When the principal in one realm needs access to a principal in another realm, the principal requests an RTGT from its TGS and then contacts the TGS for the other realm to request a session ticket for the remote service.
With user name and password authentication, the user provides his or her user name and password to authenticate. This information is typically encrypted for transport to the authentication server, but if it is intercepted, it can be cracked programmatically. This type of authentication relies on something you know.
With token-based authentication, the user is issued a device that is used for authentication. The device can be synchronized with a server with a number that changes at predetermined intervals, or it can contain user information and a certificate. This type of authentication relies on something you have.
With biometric authentication, the user is issued a sensor that scans some physical attribute of the user and sends that information to the authenticating server. The server compares a stored sample to the sample provided by the user to validate the user's identity. This type of authentication relies on something you are.
There are multiple authentication methods available, and the security offered by combining methods to form a multifactor authentication process is much greater than using any single authentication method.