The Full Wiki

NTLM: Wikis

  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

NTLM (NT LAN Manager) (not to be confused with LAN Manager) is a Microsoft authentication protocol used with the SMB protocol. MS-CHAP is similar and is used for authentication with Microsoft remote access protocols. During protocol negotiation, the internal name is nt lm 0.12. The version number 0.12 has not been explained. It is the successor of LANMAN (Microsoft LAN Manager), an older Microsoft authentication protocol, and attempted to be backwards compatible with LANMAN. NTLM was followed by NTLMv2, at which time the original was renamed to NTLMv1.

Before official documentation of the protocol was available, it was analyzed by the Samba team through network analysis. The cryptographic calculations are identical to that of MS-CHAP and are documented in RFC 2433 for v1 and RFC 2759 for v2. Both MS-CHAP v1 and v2 have been analyzed; Bruce Schneier, Peiter Mudge Zatko and David Wagner, among other researchers, found weaknesses in both protocols.[1] Still both protocols remain in widespread use.

Contents

The protocol

The protocol uses a challenge-response sequence requiring the transmission of three messages between the client (wishing to authenticate) and the server (requesting authentication):

  1. The client first sends a Type 1 message containing a set of flags of features supported or requested (such as encryption key sizes, request for mutual authentication, etc.) to the server.
  2. The server responds with a Type 2 message containing a similar set of flags supported or required by the server (thus enabling an agreement on the authentication parameters between the server and the client) and, more importantly, a random challenge (8 bytes).
  3. Finally, the client uses the challenge obtained from the Type 2 message and the user's credentials to calculate the response. The calculation methods differ based on the NTLM authentication parameters negotiated previously, but in general they apply MD4/MD5 hashing algorithms and DES encryption to compute the response. The client then sends the response to the server in a Type 3 message.

NTLMv1

NTLMv1 is a challenge-response authentication protocol. 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, e.g. a password. The client returns the 24-byte result of the computation. In fact, in NTLMv1 two computations are made using two different shared secrets and two 24-byte results are returned. The server verifies that the client has computed the correct result, and from this infers possession of the secret, and hence the identity of the client.

The two secrets are:

  • the LANMAN Hash of the user's password and
  • the MD4 hash of the user's password

Both these hashes produce 16-byte quantities. Five bytes of zeros are appended to obtain 21 bytes. The 21 bytes are separated in three 7 bytes 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 lanman hash and the MD4 hash (called the NT Hash) are returned as the response.

C = 8-byte server challenge, random
K1 | K2 | K3 = NT-Hash | 5-bytes-0
R1 = DES(K1,C) | DES(K2,C) | DES(K3,C)
K1 | K2 | K3 = LM-Hash | 5-bytes-0
R2 = DES(K1,C) | DES(K2,C) | DES(K3,C)
response = R1 | R2

NTLMv2

NTLMv2, introduced after Windows NT 4.0 SP4, is a challenge-response authentication protocol. It is intended as a cryptographically strengthened replacement for NTLMv1.

NTLMv2 sends two 16-byte responses to an 8-byte server challenge. The response is the HMAC-MD5 hash of the server challenge, a randomly generated client challenge, and a 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 (e.g. DCE/RPC Over SMB, Leighton) this response is termed LMv2.

The second response sent by NTLMv2 uses a variable length client challenge which includes (1) the current time in NT Time format, (2) an 8-byte random value, (3) the domain name and (4) 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 a hash of the user's password and other identifying information. The exact formula is to begin with the NT Hash of NTLMv1, which is stored in the SAM, 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.

CS = 8-byte server challenge, random
CC = 8-byte client challenge, random
CC* = (X, time, CC, domain name)
v2-Hash = HMAC-MD5(NT-Hash, user name, domain name)
LMv2 = HMAC-MD5(v2-Hash, CS, CC)
NTv2 = HMAC-MD5(v2-Hash, CS, CC*)
response = LMv2 | CC | NTv2 | CC*

NTLMv2-Session

The NTLMv2 Session protocol is entirely different, being very similar to MS-CHAPv2. It is described by Eric Glass' ntlm page. 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(X). 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.[2]

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 NTLMv2 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(P,SC)
  Server->DomCntl: H(P,SC), SC
  Server<-DomCntl: yes or no

NTLMv2-Session
  Client<-Server:  SC
  Client->Server:  H(P,H'(SC,CC)), CC
  Server->DomCntl: H(P,H'(SC,CC)), H'(SC,CC)
  Server<-DomCntl: yes or no

NTLM and modern Windows versions

Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and Windows 2003 Active Directory domains. Kerberos is typically used when a client belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way (such as Linux to Windows AD authentication).

NTLM is still used in the following situations:

  • 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, or doesn't belong to a domain.
  • No Active Directory domain exists (commonly referred to as "workgroup" or "peer-to-peer").
  • Where a firewall would otherwise restrict the ports required by Kerberos (of which there are quite a few)

Starting with Windows Vista, and also with Windows Server 2008, both LM and NTLM are deprecated by default. NTLM is still supported for inbound authentication, but for outbound authentication a newer version of NTLM, called NTLMv2, is sent by default instead. Prior versions of Windows (back as far as Windows NT 4.0 Service Pack 4) could be configured to behave this way, but it was not the default. Technically speaking, the computer will accept LM for inbound authentication but by default neither Windows Vista nor Windows Server 2008 store the LM hash. Therefore, there is no way for them to authenticate an inbound LM response - typical error message is System error 86 has occurred. The specified network password is not correct. You can control the authentication behavior, starting with Windows NT 4.0 Service Pack 4, using the LMCompatibilityLevel registry setting, shown in Group Policy as Network Security:LAN Manager Authentication Level. The default value for LMCompatibilityLevel in Windows Vista, Windows 7 and Windows Server 2008 is 3, or Send NTLMv2 Response Only.

See also

References

  1. ^ Schneier, Bruce; Mudge; David Wagner (1999-10-19). "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)". Cqre '99 (Springer-Verlag): 192–203. http://www.schneier.com/paper-pptpv2.html. 
  2. ^ Varughese, Sam (February 2006). "Rainbow Cracking and Password Security". Palisade. http://palisade.plynt.com/issues/2006Feb/rainbow-tables/. 

External links








Got something to say? Make a comment.
Your name
Your email address
Message