Security+ - Authentication and Identity Verification
In the preceding chapter of Security+ Essentials we looked in detail at the various levels of access control used to govern access to system resources once a user has logged into a system. While access control provides a high level of control over what a user can do once they are on the system, it does nothing to prevent unauthorized users from logging onto the system in the first place. As mentioned previously, any comprehensive IST security strategy must consist of multiple layers of security. One of the cornerstones of a good strategy involves the use of authentication and identity verification. In this chapter the various methods of authentication will be covered.
What is Authentication?
Authentication involves the preventing access to computer systems and networks to unauthorized users. Authentication takes a number of different forms, ranging from verifying account credentials (using a, amongst other things, a login name and password) to physical identity verification (using biometrics such as finger print scanning technology) to identifying that the client system form which a user is attempting to connect to a server is really the authorized client system.
Username and Password
Perhaps the most rudimentary and least secure level of authentication involves the use of a username and password to access a system. This approach simply involves presenting a user with prompts for a username and password, which if entered corrected will permit access to the system. For many year this was the primary source of authentication control.
The weakest from of username and password authentication uses plain text communication where both credentials are transmitted to the server in an unencrypted format allowing anyone eavesdropping on the connection using sniffing technology to easily identify the user name and password and use them to gain unauthorized system access. Technology such telnet use plain text when presenting authentication credentials. For this reason alone the use of telnet for providing remote access to systems has been largely discontinued in favor of encrypted alternatives.
Technologies such as Secure Shell (ssh) still use a username and password with the exception that the username and password are encrypted, making it harder for the eavesdropper to intercept and utilize these credentials.
Even with encryption, the username and password approach to authentication has a number of inherent weakness. Firstly, it identifies only and account and does nothing to verify that the person accessing the account is an authorized user. As such, the username and password can fall into the wrong hands (it is amazing how many people have their username and password written on a piece of paper stuck to their monitor) and the authentication will have no waying of knowing the wrong person is logging in.
Secondly, username and password security is only as secure as the choice of password. If a weak password is chosen it increases the chance that the password may be guessed, cracked using automated passowrd cracking technology. This problem is generally mitigated through the implementation of strict rules on passwords where users are prevented from setting up weak passwords. Password cracking may also be easily prevented by disabling an account after a specified number of invalid password entries.
Challenge Handshake Authentication Protocol (CHAP)
Approaches to authentication such username and password outline previously perform authentication once at the point that the user logs into the system. An alternative to this approach is provided by the Challenge Handshake Authentication Protocol (CHAP) which repeats an authentication procedure at random intervals during an ongoing connection between a client and a service.
The CHAP authentication scheme is used primarily by Point to Point Protocol (PPP) servers as a way to validate the identity of remote clients (perhaps most commonly used by internet service providers). At random time intervals, CHAP verifies the identity of the client by using something known as a three-way handshake. This verification is performed using a credential which is nown to both the client and the service (typically the user's password).
After the link between the client and the server (also known as the authenticator) has been established it sends a challenge message to the peer. The peer subsequently responds to the authenticator with a hashed value calculated using the Message Digest (MD%) hashing algorithm. The authenticator checks the client response against its own calculation of the expected hash value. If the two values match, the authenticator acknowledges the authentication. If the values do not match, the connect is terminated. These steps are repeated at random intervals.
It is important to note that Microsoft has implemented two variants of the Challenge Handshake Authentication Protocol, called MS-CHAP and MS-CHAP-v2.
Kerberos Authentication
Kerberos Authentication was originally developed at the Massachusetts Institute of Technology as part of a project called Athena. In an earlier section of this chapter we looked at the username and password authentication approach and discussed the inherent weaknesses of transmitting the username and password between the client and the server (such that it might be intercepted by a malicious party and used to gain unauthorized access).
The purpose of Kerberos is to provide an authentication process that does not require the transmission of username and password though the use of a symmetric-key authentication protocol. The term symmetric key in this context is used to refer to the fact that the same key is used for both the encryption and decryption processes.
In previous authentication scenarios, the process has involved two entities (the client and the server). The Kerberos Authentication process relies on a third entity called the Key Distrubution Center. The following provides a stop by step breakdown of the Kerberos authentication process:
Logon at Client
- The user enters a username and password on the client system.
- The client performs a one-way hash on the user's password, which becomes the secret key of the client.
Client Authentication
- The client system transmits a cleartext message to the Authentication Server (AS) requesting services for the user. Note that neither the secret key nor the password is sent to the Authentication Server.
- The Authentication Server checks to see if the client exists in its database. If it exists, it sends back the two messages, Client/Ticket Granting Server (TGS) session key encrypted using the secret key of the user and a Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.
- The client decrypts the TGS session key for use in further communications with TGS. The client cannot, however, decrypt the TGT message which was encrypted using TGS's secret key.
Client Service Authorization
- In order to request services, the client sends two messages to the TGS, a messaging containing the Ticket-Granting Ticket and the ID of the requested service and an authenticator message composed of the client ID and the timestamp), encrypted using the client/TGS session key.
- Upon receipt of the above messages, the TGS decrypts the messages and sends a Client-to-server ticket and a client/server session key encrypted with the client/TGS session key to the client.
Client Service Request
- Upon receiving the a Client-to-server ticket and a client/server session key, the client has enough information to authenticate itself to the server. The client connects to the server and sends the Client-to-server ticket and a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.
- The server decrypts the ticket using its own secret key and sends a message to client containing the timestamp found in client's recent Authenticator plus 1, encrypted using the client/server session key to the client to confirm its true identity.
- The client decrypts the confirmation using the client/server session key and checks whether the timestamp is correctly updated.
- Authentication is complete. The server provides the services to the client.
For all its complexity the Kerberos Authentication system is not without a few problems. First and foremost is that fact that the Key Distribution Center acts a single point of failure. If this service is unavailable it will not be possible for users to log into the service.
Secondly, the timestamps used by Kerberos requires that all systems in the process have clocks set to the same time (within 10 minutes of synchronization accuracy).
Finally, the secret keys for all users are stored on a single server which, if compromised, would in turn compromise all user keys.
Mutual Authentication
Version 5 of Kerberos Authentication introduced the concept of mutual authentication (also known as two way authentication) whereby client and server verify the authenticity of each other. This intended to prevent so-called Man in the Middle attacks whereby a malicious party inserts itself between a client and server and masquerades itself as each to the other.
Under mutual authentication, one of the two systems creates a challenge code which it transmits to the other system. The second system in turn generates a response using the received challenge code and also creates its own challenge code, and are both transmitted back to the original system. The original system validates the response code and returns its own response code based on the challenge code send from the second system. Once the second system has validated its own response code from the original system it sends an acknowledgment message and authentication is complete.
== Certificate Based Authentication
