LM Hash and NT Hash
1. The LM hash is case-insensitive, while the NT hash is case-sensitive.
2. The LM hash has a limited character set of only 142 characters, while the NT hash supports almost the entire Unicode character set of 65,536 characters.
3. The NT hash calculates the hash based on the entire password the user entered. The LM hash splits the password into two 7-character chunks, padding as necessary.
Both types of hashes generate a 128-bit stored value. Most password crackers today crack the LM hash first, then crack the NT hash by simply trying all upper and lower case combinations of the case-insensitive password cracked by the LM hash.
The LM hash is a very weak one-way function used for storing passwords. Originally invented for the LAN Manager operating system, the LM hash was included in Windows NT for backward compatibility. It is still included for backward compatibility. Because of the way the LM hash is calculated, no password with an LM hash is stronger than a 7-character password selected from a 142-character character set.
Why is the LM hash stored if it is so vulnerable?
The LM hash is stored for backward compatibility reasons. Many environments no longer need it and can disable storage of that value. This will prevent attacks against captured LM hashes from a compromised authentication server. However, it will not prevent any computer from sending the LanMan response during an authentication sequence. Storage of the LM hash can be prevented by using a password longer than 14 characters or by using certain Unicode characters in the password
The NT hash is perfectly adequate for authenticating as the user without cracking. In a very real sense, there is no difference in security value between a 1-character password stored using an LM hash and a 127-character highly complex password stored using the NT hash. Both generate a hash that can be used to authenticate as the user, and if the LM Compatibility Level value has been set to 4 or higher on the target server the LM OWF is useless anyways
How to Remove LM Hashes
There are several ways to ensure the LM hash is not stored
1. To use passwords or pass phrases longer than 14 characters.
2. Use the NoLMHash switch – “Network security: Do not store LAN Manager hash value on next password change." Using that switch globally turns off storage LM hashes for all accounts. The change will take effect the next time the password is changed. Existing LM hashes for the current and any past passwords are not removed simply by throwing that switch. (http://support.microsoft.com/?id=299656)
3. Using “ALT characters" in your password prevents the LM hash from being generated. Actually, only certain Unicode characters cause the LM hash to disappear. For instance, Unicode characters between 0128 and 0159 cause the LM hash not to be generated
Negative Effects of Removing LM hash
1. Breaks any application that uses UDP-based authentication for RPC. That includes Windows Cluster Services, Real Time Communications Server, and probably others.
2. These problems are solved by turning on the NtlmMinClientSec setting - “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients". NtlmMinClientSec needs to be set to at least Require message integrity and require NTLMv2 Session security (0x80010). When it is set to that RPC utilizes NTLMv2 authentication, which uses the NT hash.
Other applications will also break in the absence of an LM hash. For instance, Outlook 2001 for the Macintosh requires that all accounts it uses have one. Windows 3.x will definitely break without an LM hash, and Windows 95 and 98 will break in certain scenarios. In addition, some third-party products, such as network attached storage devices, may require LM hashes
Control of NTLM security is through the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA
NOTE: On Win9x, the valid registry key is LMCompatibility while on Windows NT it is LMCompatibilityLevel.
Choice of the authentication protocol variants used and accepted is through the following value of that key: Value: LMCompatibilityLevel
Value Type: REG_DWORD
Number Valid Range: 0-5
Default: 0 Description:
This parameter specifies the type of authentication to be used.
Level 0 - Send LM response and NTLM response; never use NTLMv2 session security
Level 1 - Use NTLMv2 session security if negotiated
Level 2 - Send NTLM authentication only
Level 3 - Send NTLMv2 authentication only
Level 4 - DC refuses LM authentication
Level 5 - DC refuses LM and NTLM authentication (accepts only NTLMv2)
NOTE: Authentication is used to establish a session (username/password). Session security is used once a session is established using the appropriate type of authentication. Also system times should be within 30 minutes of one another. Authentication can fail because the server will think the challenge from the client has expired.
BUT, when we apply “Disable LANMAN" via Group Policy, it will override the registry settings as the Group policy will again change the Registry Settings.
1. The LM hash is case-insensitive, while the NT hash is case-sensitive.
2. The LM hash has a limited character set of only 142 characters, while the NT hash supports almost the entire Unicode character set of 65,536 characters.
3. The NT hash calculates the hash based on the entire password the user entered. The LM hash splits the password into two 7-character chunks, padding as necessary.
Both types of hashes generate a 128-bit stored value. Most password crackers today crack the LM hash first, then crack the NT hash by simply trying all upper and lower case combinations of the case-insensitive password cracked by the LM hash.
The LM hash is a very weak one-way function used for storing passwords. Originally invented for the LAN Manager operating system, the LM hash was included in Windows NT for backward compatibility. It is still included for backward compatibility. Because of the way the LM hash is calculated, no password with an LM hash is stronger than a 7-character password selected from a 142-character character set.
Why is the LM hash stored if it is so vulnerable?
The LM hash is stored for backward compatibility reasons. Many environments no longer need it and can disable storage of that value. This will prevent attacks against captured LM hashes from a compromised authentication server. However, it will not prevent any computer from sending the LanMan response during an authentication sequence. Storage of the LM hash can be prevented by using a password longer than 14 characters or by using certain Unicode characters in the password
The NT hash is perfectly adequate for authenticating as the user without cracking. In a very real sense, there is no difference in security value between a 1-character password stored using an LM hash and a 127-character highly complex password stored using the NT hash. Both generate a hash that can be used to authenticate as the user, and if the LM Compatibility Level value has been set to 4 or higher on the target server the LM OWF is useless anyways
How to Remove LM Hashes
There are several ways to ensure the LM hash is not stored
1. To use passwords or pass phrases longer than 14 characters.
2. Use the NoLMHash switch – “Network security: Do not store LAN Manager hash value on next password change." Using that switch globally turns off storage LM hashes for all accounts. The change will take effect the next time the password is changed. Existing LM hashes for the current and any past passwords are not removed simply by throwing that switch. (http://support.microsoft.com/?id=299656)
3. Using “ALT characters" in your password prevents the LM hash from being generated. Actually, only certain Unicode characters cause the LM hash to disappear. For instance, Unicode characters between 0128 and 0159 cause the LM hash not to be generated
Negative Effects of Removing LM hash
1. Breaks any application that uses UDP-based authentication for RPC. That includes Windows Cluster Services, Real Time Communications Server, and probably others.
2. These problems are solved by turning on the NtlmMinClientSec setting - “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients". NtlmMinClientSec needs to be set to at least Require message integrity and require NTLMv2 Session security (0x80010). When it is set to that RPC utilizes NTLMv2 authentication, which uses the NT hash.
Other applications will also break in the absence of an LM hash. For instance, Outlook 2001 for the Macintosh requires that all accounts it uses have one. Windows 3.x will definitely break without an LM hash, and Windows 95 and 98 will break in certain scenarios. In addition, some third-party products, such as network attached storage devices, may require LM hashes
Control of NTLM security is through the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA
NOTE: On Win9x, the valid registry key is LMCompatibility while on Windows NT it is LMCompatibilityLevel.
Choice of the authentication protocol variants used and accepted is through the following value of that key: Value: LMCompatibilityLevel
Value Type: REG_DWORD
Number Valid Range: 0-5
Default: 0 Description:
This parameter specifies the type of authentication to be used.
Level 0 - Send LM response and NTLM response; never use NTLMv2 session security
Level 1 - Use NTLMv2 session security if negotiated
Level 2 - Send NTLM authentication only
Level 3 - Send NTLMv2 authentication only
Level 4 - DC refuses LM authentication
Level 5 - DC refuses LM and NTLM authentication (accepts only NTLMv2)
NOTE: Authentication is used to establish a session (username/password). Session security is used once a session is established using the appropriate type of authentication. Also system times should be within 30 minutes of one another. Authentication can fail because the server will think the challenge from the client has expired.
BUT, when we apply “Disable LANMAN" via Group Policy, it will override the registry settings as the Group policy will again change the Registry Settings.
