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 prevention of unauthorized access to computer systems. Authentication takes a variety of forms, ranging from verifying account credentials (using, 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 from 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 correctly will permit access to the system. For many years this was the primary method of authentication control.
The weakest form 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 subsequently use them to gain unauthorized system access. Remote access technology such as 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 (as is all data transmitted after authentication has taken place"), 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 weaknesses. Firstly, it identifies only the 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 way 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 or cracked using automated password 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 prevented by disabling an account after a specified number of invalid password attempts.
Challenge Handshake Authentication Protocol (CHAP)
Approaches to authentication such username and password outlined previously perform authentication only 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 known 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 (MD5) 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 also 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 step 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 two messages, a 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 use of timestamps by Kerberos dictates that all systems in the process have clocks set to the same time (or 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.
For more detailed information on Kerberos Authentication refer to the Kerberos Installation, User and Administration guides.
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 is intended to prevent so-called Man in the Middle attacks whereby a malicious party inserts a system 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, both of which transmitted back to the original system. The original system validates the response code and returns its own response code based on the challenge code sent from the second system. Once the second system has validated the response code from the original system it sends an acknowledgment message and authentication is complete.
Certificates
Certificate security provides a mechanism for achieving encrypted communications over unsecured networks and is built upon the Public Key Infrastructure (PKI). Certificates use asymmetrical cryptography whereby different keys are used for the encryption and decryption process.
Under public key encryption two keys are required, a public key and a private key. A client contacts a Certificate Authority (CA) to obtain both of these keys. The public key is then provided to anyone who needs to send encrypted data to the client. The sender uses the this public key to encrypt the data and send it to the original client. On reciept, the client decrypts the message using the private key (which is the only key which can be used to decrypt the message since this is asymmetrical encryption.
So far we have looked at certificates in terms of encrypting data between parties where the public key is used to encrypt a message to a client and the client's private key is used to decrypt the message. When using certificates as a means of authentication this process is reversed. In such a situation the client encrypts its signature using its private key and sends it to the receiving system. If the sending client is who it claims to be the receiving system should be able to decrypt the signature using the client's public key. If the decryption using the public key fails, the sender is not who they claim to be and the authentication has failed.
Authentication using Tokens
Tokens involve the use of what are essentially one time passwords to gain access to a system. These tokens can be generated using small devices such as smart cards or key ring devices which display a new token each time the user press a button, which is used to gain access to a system or server. Each token is unique and used only once, avoiding the problem of password falling into the wrong hands. Even if a token was to fall into the wrong hands it would be invalid before they had a chance to use it to gain unauthorized access.
Biometrics
Once the confined to spy movies where the finger or eye ball of an unfortunate government employee would be removed and scanned to gain access to a secure area, biometrics are now very much a reality.
Biometrics involve the use of some part of a persons body as form of identification. Most common devices for this purpose are finger print scanners (which are even now included on some laptop models) which deny access to a system until a suitable fingerprint match is scanned by the reader.
Other possible biometric identification possibilities include retinal scans and voice recognition.
