According to documentation, level 1 still sends the LM response and the NTLMv2 response in place of NTLM when possible. Ordinarily, L0phtCrack 2.5 cracks the all-uppercase LM passwords, then quickly works through all possible case variations to determine the case-sensitive NT versions of the password. In theory, L0phtCrack would need to crack only the LM responses, leaving the intruder to figure out the case-sensitive version, because L0phtCrack can't crack NTLMv2 responses. However, with level 1, I fully cracked captured authentications to the case-sensitive level, which means the client sent the NTLM response instead of the NTLMv2 response and suggests some possible bugs with level 1 negotiation. The bottom line is that level 1 is vulnerable to both dictionary and brute force attacks on the LM response.
Level 2. Level 2 specifies NTLM authentication only. When using L0phtCrack's SMB Packet Capture mode against a level 2 system, intruders might expect to see only the NT Hash column filled with data and the LanMan Hash column filled with zeros. As Screen 2, line 3 shows, both response columns have the same value. With level 2, NT fills both the NT Hash and LanMan Hash columns with the NTLM response. This response pair lets SP4 or later level 2 clients connect to downlevel servers using a domain account without sending the LM response. Because the downlevel servers understand only LM authentication, they ignore the NT response and forward the LM response to the domain controller. If the domain controller has SP4 or later, the authentication will work.
Level 2 defeats L0phtCrack's default mode, which concentrates on the LM response. In this case, L0phtCrack uses the LM crack algorithm on an NT response. An intruder can still configure L0phtCrack to perform a dictionary attack on the NT response to find the password. But passwords that require the dictionary/brute hybrid attack will probably take too long to crack to be of interest to an intruder, and passwords that require brute force might take years to crack, even with many systems sharing the crack workload. So, to eliminate LM vulnerabilities, set your workstations to level 2, but remember that with level 2, low-quality passwords are still susceptible to cracking.
Level 3. Level 3 specifies NTLMv2 authentication only. When an intruder sniffs a level 3 authentication, the NT Hash column fills with the NTLMv2 response and the LanMan Hash column fills with a LMv2 response.
Microsoft had planned to substitute the LM response with the NTLMv2 response to provide pass-through authentication to downlevel servers, but NTLMv2 responses are longer than 24 bytes. The NTLM authentication protocol specifies that response slots have variable length, therefore downlevel servers should forward the whole response to the domain controller. However, downlevel OSs aren't protocol-compliant and forward only the first 24 bytes of the LM response to the domain controller. So, Microsoft created a 24-byte LMv2 response, which level 3 clients send as an LM response and L0phtCrack records in the LanMan Hash column.
LMv2 is more secure than NTLM, because it computes a 128-bit (rather than NTLM's 56-bit) secret from the password. L0phtCrack 2.5 can't crack responses that have the NTLMv2 and LMv2 combination.
Until L0pht Heavy Industries updates L0phtCrack to crack NTLMv2 responses, level 3 would be very secure, if it worked. In my repeated experiments, level 3 clients consistently failed to log on to SP4 or later servers, regardless of the server's LMCompatibilityLevel. Using an account on the domain controller, I issued the Net Use command to connect to a shared folder on a domain controller. In my testing, level 3 didn't work at all. At press time, Microsoft hadn't responded to the level 3 problem.
Level 4. Level 4 documentation is somewhat ambiguous. In some places, the documentation says level 4 refuses LM authentication, which could mean that level 4 will refuse any client that sends the LM response. Elsewhere, the documentation says level 4 refuses downlevel clients. On testing level 4, I verified that it applies to only downlevel clients. For example, on my server, level 4 refused a connection from my DOS workstation running LAN Manager client software, but level 4 didn't refuse connections from NT clients, even when they sent the LM response. Of course, level 4 doesn't apply to downlevel clients connecting to a non-domain-controller server with a domain account, because the server simply forwards the credentials to the domain controller.
Level 4 specifies that servers refuse connections from downlevel clients using a local account on that server and that domain controllers refuse any connection from downlevel clients. Therefore, you can use level 4 to make sure that you have no downlevel clients sending the vulnerable LM response. However, you can't use level 4 to prevent connections from NT clients that are still sending the LM response. For NT systems, you must prevent the transmission of the LM response at the workstation level by using SP4 or later and LMCompatibilityLevel 2 or above.
Level 5. Level 5 specifies the refusal of clients that send anything but NTLMv2 responses. (Level 5 observes the same exception as level 4 for pass-through authentication to non-domain-controller servers.) You could use level 5 to enforce the highest security and make sure that all clients are NTLMv2-compliant, but level 5 unfortunately has some bugs. In my testing, level 5 servers refused all connections, including properly configured NTLMv2 clients. Microsoft has acknowledged this serious bug, but hadn't released a fix as of press time. SP5 didn't address this problem.
Balancing Security and Compatibility
Of course, life is much simpler and safer if all workstations and servers are NT and SP4 or later. With legacy applications that require downlevel OSs, you need to consider the time needed to apply service packs and the possibility of introducing stability problems. You will want to know exactly which systems require updates in each scenario. You can save a lot of time by using System Policy Editor (SPE) to update the Registry and using the resource kit's Autoexnt utility to apply service packs. For information about using the resource kit's Autoexnt utility, see "Managing Service Packs and Hotfixes," http://www.winntmag.com, InstaNT document number 4996.
Whenever possible, you need to prevent your clients from transmitting the LM response. So, until Microsoft resolves the problems with level 3, I recommend implementing level 2. To avoid having workstations that can't connect to your servers, you need to follow these three steps to update your systems in the correct order.
- Install SP4 or later on all domain controllers. (This rule doesn't apply to resource domain controllers because they forward responses to the domain controller in which the account resides.) If your current account is on an SP4 or later domain controller, you can use a level 2 or 3 workstation to map drives to a pre-SP4 server in a trusted domain in which the trusted domain controllers haven't applied SP4 or later.
- Identify any downlevel systems such as file or print servers. You need to identify these systems, because level 2 NT workstations can't connect to downlevel computers that use share-level security and non-null passwords. Downlevel systems let you share files by using user-level or share-level security. Share-level security requires downlevel systems to validate the response locally against the share-level password, but on NT clients, the validation will fail because downlevel systems don't understand NTLM responses. If you're using a domain account, user-level security will work because the downlevel system will forward the response to the domain controller. You need to upgrade the downlevel servers to NT or switch to user-level security with domain accounts.
- Identify any pre-SP4 NT servers using local accounts instead of domain accounts. You'll need to upgrade these servers to SP4 or later because they'll perform authentication locally and won't understand responses from level 2 clients.
A Few Last Words of Advice
I want to close this technical discussion by making sure you know where to go from here for best possible security. Remember the two main risks from sniffed authentication and subsequent cracking—dictionary cracks and brute force attacks. First, intruders will attack the captured response with a dictionary crack that will quickly uncover any poor password. All versions of the NT response are vulnerable to a dictionary attack. LM and NTLM responses are vulnerable to currently available intruder tools. The NTLMv2 response is vulnerable, but no intruder tools are yet available to exploit it. Second, intruders can launch brute force attacks to crack higher-quality passwords. LM responses built from even complex passwords are extremely vulnerable to brute force attacks—to the point of requiring only trivial effort. NTLM responses built from complex passwords are less vulnerable to brute force, but when hardware gets faster, this resistance will change. NTLMv2 provides much stronger protection against brute force attacks. But when L0pht Heavy Industries revises L0phtCrack, NTLMv2 might be vulnerable to dictionary attacks on poor-quality passwords.
A crucial distinction exists between threats that are theoretical and threats from currently available tools. Corporations suffer the most losses from intruders who don't know how to write a tool such as L0phtCrack but can definitely use one.
The moral of the security story is threefold. First, require long high-quality passwords from your users. As a start, I recommend that users create password phrases in which the first letter of each word makes up the password, then intersperse numbers and symbols. You need to use PassProp and password-notification packages (e.g., passfilt.dll) to enforce stronger password requirements. Second, use the strongest possible version of NT authentication. Try to eliminate LM authentication altogether, because intruder tools can easily crack high-quality passwords when using LM responses. To eliminate LM authentication, you'll need to upgrade your NT systems to SP4 or later and use LMCompatibilityLevel 2. When Microsoft makes fixes available for LMCompatibilityLevel 3 and 5, move your workstations to level 3 and your servers and domain controllers to level 5. As for the downlevel clients, the sooner you replace them, the better your security and total cost of ownership (TCO) will be. NTLM authentication will always be subject to sniffing and cracking, especially with low-quality passwords.
Finally, look forward to the future—Windows 2000 (Win2K) replaces NTLM with Kerberos and extends the Kerberos standard to support certificates stored on smart cards. Let's hope these enhancements will provide permanent protection for network authentication.