NTLM


In a Windows network, NT LAN Manager is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager, an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system, which is governed by Group Policy settings, for which different versions of Windows have different default settings.
NTLM passwords are considered weak because they can be brute-forced very easily with modern hardware.

Protocol

NTLM is a challenge–response authentication protocol which uses three messages to authenticate a client in a connection-oriented environment, and a fourth additional message if integrity is desired.
  1. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities.
  2. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client.
  3. Finally, the client responds to the challenge with an AUTHENTICATE_MESSAGE.
The NTLM protocol uses one or both of two hashed password values, both of which are also stored on the server, and which through a lack of salting are password equivalent, meaning that if you grab the hash value from the server, you can authenticate without knowing the actual password. The two are the LM hash, and the NT hash. Both hash values are 16 bytes each.
The NTLM protocol also uses one of two one-way functions, depending on the NTLM version; NT LanMan and NTLM version 1 use the DES-based LanMan one-way function, while NTLMv2 uses the NT MD4 based one-way function.

NTLMv1

The server authenticates the client by sending an 8-byte random number, the challenge. The client performs an operation involving the challenge and a secret shared between client and server, specifically one of the two password hashes described above. The client returns the 24-byte result of the computation. In fact, in NTLMv1 the computations are usually made using both hashes and both 24-byte results are sent. The server verifies that the client has computed the correct result, and from this infers possession of the secret, and hence the authenticity of the client.
Both the hashes produce 16-byte quantities. Five bytes of zeros are appended to obtain 21 bytes. The 21 bytes are separated in three 7-byte quantities. Each of these 56-bit quantities is used as a key to DES encrypt the 64-bit challenge. The three encryptions of the challenge are reunited to form the 24-byte response. Both the response using the LM hash and the NT hash are returned as the response, but this is configurable.

C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
response = DES | DES | DES

NTLMv2

NTLMv2, introduced in Windows NT 4.0 SP4, is a challenge-response authentication protocol. It is intended as a cryptographically strengthened replacement for NTLMv1, enhancing NTLM security by hardening the protocol against many spoofing attacks and adding the ability for a server to authenticate to the client.
NTLMv2 sends two responses to an 8-byte server challenge. Each response contains a 16-byte HMAC-MD5 hash of the server challenge, a fully/partially randomly generated client challenge, and an HMAC-MD5 hash of the user's password and other identifying information. The two responses differ in the format of the client challenge. The shorter response uses an 8-byte random value for this challenge. In order to verify the response, the server must receive as part of the response the client challenge. For this shorter response, the 8-byte client challenge appended to the 16-byte response makes a 24-byte package which is consistent with the 24-byte response format of the previous NTLMv1 protocol. In certain non-official documentation this response is termed LMv2.
The second response sent by NTLMv2 uses a variable-length client challenge which includes the current time in NT Time format, an 8-byte random value, the domain name and some standard format stuff. The response must include a copy of this client challenge, and is therefore variable length. In non-official documentation, this response is termed NTv2.
Both LMv2 and NTv2 hash the client and server challenge with the NT hash of the user's password and other identifying information. The exact formula is to begin with the NT hash, which is stored in the SAM or AD, and continue to hash in, using HMAC-MD5, the username and domain name. In the box below, X stands for the fixed contents of a formatting field.

SC = 8-byte server challenge, random
CC = 8-byte client challenge, random
CC* = 
v2-Hash = HMAC-MD5
LMv2 = HMAC-MD5
NTv2 = HMAC-MD5
response = LMv2 | CC | NTv2 | CC*

NTLM2 Session

The NTLM2 Session protocol is similar to MS-CHAPv2. It consists of authentication from NTLMv1 combined with session security from NTLMv2.
Briefly, the NTLMv1 algorithm is applied, except that an 8-byte client challenge is appended to the 8-byte server challenge and MD5-hashed. The least 8-byte half of the hash result is the challenge utilized in the NTLMv1 protocol. The client challenge is returned in one 24-byte slot of the response message, the 24-byte calculated response is returned in the other slot.
This is a strengthened form of NTLMv1 which maintains the ability to use existing Domain Controller infrastructure yet avoids a dictionary attack by a rogue server. For a fixed X, the server computes a table where location Y has value K such that Y=DES_K. Without the client participating in the choice of challenge, the server can send X, look up response Y in the table and get K. This attack can be made practical by using rainbow tables.
However, existing NTLMv1 infrastructure allows that the challenge/response pair is not verified by the server, but sent to a Domain Controller for verification. Using NTLM2 Session, this infrastructure continues to work if the server substitutes for the challenge the hash of the server and client challenges.

NTLMv1
 Client<-Server: SC
 Client->Server: H
 Server->DomCntl: H, SC
 Server<-DomCntl: yes or no
NTLM2 Session
 Client<-Server: SC
 Client->Server: H, CC
 Server->DomCntl: H, H'
 Server<-DomCntl: yes or no

Availability and use of NTLM

Since 2010, Microsoft no longer recommends NTLM in applications:
Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy checks or MD5 for integrity, and RC4 for encryption.
Deriving a key from a password is as specified in RFC1320 and FIPS46-2. Therefore, applications are generally advised not to use NTLM.

Despite these recommendations, NTLM is still widely deployed on systems. A major reason is to maintain compatibility with older systems. However, it can be avoided in some circumstances.
Microsoft has added the NTLM hash to its implementation of the Kerberos protocol to improve interoperability. According to an independent researcher, this design decision allows Domain Controllers to be tricked into issuing an attacker with a Kerberos ticket if the NTLM hash is known.
Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains. Kerberos is typically used when a server belongs to a Windows Server domain. Microsoft recommends developers neither to use Kerberos nor the NTLM Security Support Provider directly.

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

Use of the NTLM Security Support Provider

The NTLM SSP is used in the following situations:
  • The client is authenticating to a server that doesn't belong to a domain or no Active Directory domain exists
  • * The server must have the "password-protected sharing" feature enabled, which is not enabled by default and which is mutually exclusive with HomeGroup on some versions of Windows.
  • * When server and client both belong to the same HomeGroup, a protocol similar to Kerberos, Public Key Cryptography based User to User Authentication will be used instead of NTLM. HomeGroup is probably the easiest way to share resources on a small network, requiring minimal setup, even compared to configuring a few additional users to be able to use password-protected sharing, which may mean it is used much more than password-protected sharing on small networks and home networks.
  • If the server is a device that supports SMB, such as NAS devices and network printers, the NTLM SSP may offer the only supported authentication method. Some implementations of SMB or older distributions of e.g. Samba may cause Windows to negotiate NTLMv1 or even LM for outbound authentication with the SMB server, allowing the device to work although it may be loaded with outdated, insecure software regardless of whether it were a new device.
  • If the server is a member of a domain but Kerberos cannot be used.
  • * The client is authenticating to a server using an IP address
  • * The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust
  • * Where a firewall would otherwise restrict the ports required by Kerberos