NTLM, or new technology LAN manager, is a Windows default authentication protocol introduced in 1993 to replace LAN manager, or LM. Compared to its predecessor, NTLM provided several significant improvements, such as using hashing instead of transmitting the user’s real passwords and offering authorization and authentication by creating user tokens.


NTLM is a challenge-response authentication protocol for authentication. When a system requesting authentication connects to a server, the server challenges the system to provide a valid hashed response. This process allows user credentials to be verified without sending the password directly over the network.


You may already know that NTLM was eventually replaced by the open-source Kerberos protocol. But you may not know that Microsoft released a second version of NTLM, lacklusterly named NTLMv2. While it was an obvious improvement over the original version, without mutual authentication and proper SSO support, NTLMv2 couldn’t compete with Kerberos.


It may seem like Windows spent a lot of time developing a flawed authentication protocol. But what you should remember is that both the cybersecurity and cybercrime landscape was much less complex compared to today. Back then, NTLM worked fine, but it wasn’t as advanced as Kerberos.

NTLM authentication process is based on a challenge-response model where the client (the user’s machine) attempts to access a resource on a server and sends a request. In response, the server sends a challenge to the client, a randomly generated number. To complete the challenge and prove it knows the user’s password, the client uses the number to hash the user’s password. The domain controller plays a key role in NTLM authentication, verifying the identity of users and managing their access to resources on the network. The use of hashing and encryption ensures that the user’s secured NTLM credentials are not directly transmitted over the network.


The challenge-response authentication model consists of three steps:
Negotiation message. The client sends a negotiation message, or Type 1, message to the server. This message contains information about the client’s capabilities, such as its highest NTLM version support. Challenge message. The server responds to the negotiation message by sending back a challenge message, or Type 2, message. This message contains a randomly generated server challenge and other details about the server’s capabilities. Authentication message. The server verifies the client’s response. If the client’s response is correct, the server grants access to the requested resource.

Most NTLM security concerns revolve around its encryption. For example, the lack of support for modern cryptography, such as AES and SHA-256, make it vulnerable to various cyberattacks such as relay, pass-the-hash, and brute-force attacks. For example, in a pass-the-hash attack, the attacker impersonates a user by using their username and password hash that can be found in various places in both the client and server side.


Or because the NTLM doesn’t support password salting, the same password will result in the same hash. An attacker can use a database of millions of passwords and hashes to find the right one.


NTLM also does not support MFA (multi-factor authentication), which can significantly boost security because knowing the password is not enough to get access to a system. But without MFA, once an attacker obtains a password hash, they can potentially access the system without additional authentication.

{SHORTCODES.blogRelatedArticles}

Even though Kerberos was created 10 years earlier than NTLM, better technology allowed it to end up ahead and start replacing NTLM on Windows systems. Let’s see the differences between the two authentication methods.

Simpler configuration. NTLM is easier to configure and set up compared to Kerberos. Windows support. NTLM is supported by many systems, including older Windows versions. Connectionless authentication. It means that each request can be independently authenticated without relying on a session state. NTLM proxy. A proxy can provide a way for non-NTLM aware applications to communicate using NTLM authentication securely. Weaker security. The hashing-based authentication used by NTLM is not as strong as the encryption approach used by Kerberos. Lack of SSO support. In NTLM, users have to reenter their credentials to access different resources. Vulnerable to cyberattacks. Outdated cryptography and weak encryption make NTLM vulnerable to cyberattacks, such as pass-the-hash and pass-the-ticket attacks. Modern cryptography. Its cryptography is fully prepared to face modern cybersecurity challenges. Mutual authentication. Since both the client and the server authenticate each other, they help prevent man-in-the-middle attacks. Access control. Kerberos enables you to control who can and cannot enter the network. Time-sensitive ticket system. Kerberos relies on a strict, time-based ticketing system, providing a much more secure environment. SSO. Single-sign on helps users with efficiency because after authenticating once, they don’t need to do it again. Complexity. Kerberos requires more configuration and setup compared to NTLM, making it more difficult to deploy and maintain. Time synchronization. While generally its an advantage, Kerberos relying on accurate time synchronization between servers can also be a challenge in environments spanning across several time zones. Compatibility Issues. Older systems may not be compatible with Kerberos, limiting how you can use it in some networks.

NTLM was sufficient for a little while but failed to keep up with the advancing hacking techniques. As we mentioned, NTLM does not support salting. Salting and peppering are two cryptographic methods of altering a hash, so that the same content does not create the same hash value. In general, you may want the same version of software to have the same hash but not in passwords. If the system keeps passwords unsalted, an attacker can compare the hash to their collection of millions of password hashes and discover the password.


While it was a significant one, it was not the only reason why NTLM had to give way to Kerberos authentication. Raising rates of cybercrime drove the demand for stronger encryption algorithms, and NTLM simply couldn’t deliver sufficient protection.