Changes

Jump to: navigation, search
no edit summary
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 connection 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.
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 Distribution Center''. The following provides a step by step breakdown of the Kerberos authentication process:
=== Logon at Client ===
* 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 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 the 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.
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 are 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 receipt, 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 passwords 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 limited to 1970's spy movies where the finger or eye ball of an unfortunate government employee would be removed by evil spies and scanned to gain access to a secure area, biometrics are now very much a reality.
Biometrics involve involves the use of some part of a persons person's 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.

Navigation menu