Authentication can be performed in several different ways, including the following:

■ Something you know—Passwords
■ Something you have—Tokens, smart cards, and certifi cates
■ Something you are—Biometrics

Password Authentication

Password authentication typically fails for a number of reasons: The account holder loses control of the password; the password is weak, simple, and easy to guess; or the authentication system is not designed securely so that passwords are not protected in transit. Passwords present a big problem.

Password Hashing

Most modern operating systems such as Windows or Linux encrypt the password and store it in some form of a hashed equivalent to keep it from being revealed.

Windows NT Challenge/Response, also known as NT LAN Manager (NTLM), is one of the older ones and is shown in the following list along with some other authentication schemes.
■ LM Authentication —Based on DES, this was used by Windows 95, 98, and Me.
■ NTLM —Based on DES and MD4, this was used until Windows NT Service Pack 3.
■ NTLMv2 —Based on MD4 and MD5, this was used after Windows NT Service Pack 2.
■ Kerberos —Developed by MIT, this was fi rst implemented in Windows 2000.

The LM authentication is particularly vulnerable as it truncates the password to 14 characters, converts the password to uppercase, and pads the result if the total number of characters is fewer than 14.

Finally, to make matters worse, the password is divided into two 7-character fields. The two hashed results are concatenated and stored as the LM hash, which is stored in the Security Accounts Manager (SAM).

Linux systems also use a salt. Salts are used to add a layer of randomness to the passwords. Because MD5 is a hashing algorithm, this means that if you used letmein for your password and another person used letmein for their password, the encrypted values would look the same. A Linux salt can be one of 4,096 values and helps further scramble the password.


Ubuntu, Mac OS X, and BSD, have started using techniques to slow down the password cracking process.
This forces the attacker to do a lot of extra processing for each possible hashed password value. One example is bcrypt. Bcrypt is a key derivation function that is derived from the Blowfi sh cipher. Bcrypt is an adaptive function that is designed to slow brute-force attacks and force the attacker to use increasing amounts of computation power. You can identify Bcrypt passwords, as they begin with $2a$. Another big change is that passwords have been moved out of the etc/passwd file, and into the etc/shadow file. Storing passwords in the etc/shadow file provides
some additional security because only root has access.


A challenge-and-response authentication session works like this:

1. The client computer requests a connection to the server.
2. The server sends a secret value or nonce to the client.
3. The client encrypts the secret value using a hashed password and transmits the result to the server.
4. The server decrypts the secret value using the stored hashed password and compares it to the original secret value to decide whether to accept the logon.

Example ( the actually CR will be more mathematical and complex)



Challenge-response can be either asynchronous or synchronous.

Synchronous systems are synchronized to the authentication server. This means that each time a client authenticates itself, the passcode or authentication is valid for only a short period of time.

Asynchronous and synchronous systems work because the hashed password is never transmitted over the network; only a random value and an encrypted random value are sent.

Session Authentication

Unlike challenge-response, session authentication validates users once and creates a session value that represents that authentication. This form of authentication is widely used on websites. Instead of passing an actual username and password, session authentication is passed by either cookies or query strings to the server. Session authentication ensures that after authentication has occurred,  all subsequent communications can be trusted.

Session Cookies
An example of session authentication via cookies is shown here:

HTTP/1.1 302 Found
Date: Sat, 09 Sep 2006 16:09:03 GMT
Server: Apache/2.0.48 (linux) mod_ssl/2.0.48 OpenSSL/0.9.8a PHP/4.4.0
X-Powered-By: PHP/4.4.0
Set-Cookie: authenticate=1232531221
Location: index0.php
Content-Length: 1927
Content-Type: text/html; charset=ISO-8859-0

One problem with this type of authentication is session stealing. This occurs when an attacker manages to get a copy of your session cookie, generally while the cookie is being transmitted over the network. A variety of tools are available for these types of attacks, such as Cookie Cadger and Session Thief. While this problem typically occurs when data is being sent in cleartext and the cookie is not encrypted, it has been used quite often over the last few years and has resulted in well-known web services such as Gmail, Facebook, and Twitter moving to HTTPS for all communication.

Certificate-Based Authentication

Certificate-based authentication is the strongest form of authentication discussed so far. When users attempt to authenticate, they present the web server with their certificates. The certificate contains a public key and the signature of the Certificate Authority. The web server must then verify the validity of the certificate’s signature and authenticate the user by using public key cryptography.


Tunneling Techniques to Obscure Traffic