NTLM

Link to the original

Introduction

The NTLM protocol is an authentication protocol used in Microsoft environments. In particular, it allows a user to prove their identity to a server in order to use a service offered by that server.

There are two possible scenarios here:

• Local account. The user uses credentials from a local account on the server. In this case, the server has the user’s key in its local database and can authenticate the user.
• Domain account. In an Active Directory environment, the user authenticates with a domain account. In this case, the server must contact the domain controller to verify the information provided by the user.

In both cases, authentication begins with a challenge/response phase between the client and the server.

Challenge - Response (main principle)

The Challenge - Response principle is used so that the server can verify whether the user knows the key for the account they are authenticating with, without transmitting the password over the network.

In cryptography, this is called a zero-knowledge proof.

This exchange has three stages:

1. Negotiation: the client tells the server that it wants to authenticate to it (NEGOTIATE_MESSAGE).
2. Challenge: the server sends a challenge to the client. This is simply a 64-bit random value that changes with each authentication request (CHALLENGE_MESSAGE).
3. Authenticate: the client encrypts the previously received challenge using a hashed version of its password as the key, then returns this encrypted version to the server together with its username and possibly its domain (AUTHENTICATE_MESSAGE).

The client uses a hashed version of its password as the key so that servers do not need to store user passwords in plaintext. Instead, the password hash is stored.

This hash is the NT hash, which is simply the result of the MD4 function, with no salt and nothing else.

NThash = MD4(password) = RC4(password)

Local account

1. The server sends a Challenge.
2. The client encrypts this challenge with the hash of its password and sends it back to the server together with the username.
3. The server looks for the user’s password hash in its SAM database.
4. After receiving it, the server also encrypts the challenge it sent earlier (1) with this hash.
5. It compares its result with the one returned by the user. If they match, the user is authenticated. Otherwise, the user did not provide the correct password.

Domain account

1. As before, the server sends a Challenge.
2. The client again encrypts this challenge with the hash of its password and sends it back to the server together with the username and domain name.
3. The server sends the information (plaintext Challenge + client-encrypted Challenge + username and domain name) to the domain controller over a secure channel using the Netlogon service.
4. After receiving this information, the domain controller also encrypts the challenge using the user’s hash stored in its NTDS.DIT database.
5. The domain controller can compare its result with the one returned by the user. If they match, the user is authenticated. Otherwise, the user did not provide the correct password.
6. In both cases, the domain controller sends the information back to the server.