In-Depth
Defending Against Weak Authentication Protocols and Passwords
Passwords protect user logon and resource access, but only if the underlying authentication protocols are secure. Here's how to overcome vulnerabilities of older protocols.
- By Derek Melber
- 11/10/2004
It is an almost certainty that your networks are vulnerable to easy attacks and password cracks. Unless you take immediate action to protect your passwords, you might be at risk. Understanding the authentication protocols and the risks is a good start, but you have to go further. You must defend against these weak password hashes and how they affect the computers on your network.
The insecurity I've described stems from authentication protocols that Microsoft supports. Microsoft has released many versions of authentication protocols over the years and continues to work on more-secure solutions. However, current networks don _ t always run the latest operating systems that support the latest and most secure authentication protocols; some computers will be running run the older, antiquated-authentication protocols.
The older protocols I'm talking about include:
LAN Manager
- NT LAN Manager
- NT LAN Manager v2
- Kerberos
To understand the vulnerabilities within each protocol, I will describe each protocol and the features that it provides. In many cases, the features are not very appealing, which is why the protocol should be avoided if possible. Then, I will review measures you can take to protect against the use of these insecure protocols and their insecure behavior.
LAN Manager
LAN Manger (LM) was first introduced back in the Windows for Workgroups 3.11, during which time security was not much of an issue. That explains why the authentication protocol LM was not very secure either. There was really no need at that time. The features that LM possess are not very lavish, but it is important to see what the protocol can do, to see why it should not be used.
The hash is case-insensitive
The character set is limited to 142 characters
Maximum length of password is 14 characters
The hash is broken down into 2-7 character chunks; if the password is shorter than 14 characters, the password will be padded with nulls to get the password to 14 characters
The hash result is a 128-bit value
The hash is one-way function
NT LAN Manager
NT LAN Manager (NTLM) followed LM and was required when Microsoft released Windows NT 3.1. A new authentication protocol was required with Windows NT 3.1 because of the new domain structure that the O/S introduced. The new domain structure meant that domain controllers would be responsible for storing the password hashes for domain user accounts. Unfortunately, the NTLM features are the same as for LM, so problems such as insecure password hashes were not solved. NTLM v2
The next time Microsoft released a new authentication protocol was deep into the Windows NT 4.0 timeline. In Service Pack 4, Microsoft released NTLM version 2 -- t was overdue, but the results were worth the wait. The new authentication protocol added several new security features and benefits that made LM and NTLM obsolete, including:
- Passwords could now be up to 128 characters long
- Mutual authentication between the client and server is supported %% Longer keys to produce a stronger password hash
Kerberos
Microsoft did not wait very long for its next authentication protocol, Kerberos. Kerberos was released with Windows 2000 and Active Directory. Kerberos is a trusted and known authentication protocol in the computing world, mainly used by Unix. Kerberos is in its fifth version as defined in the Internet Engineering Task Force _ s (IETF) Request For Comments (RFC) 1510. The stability and security of Kerberos made it an easy sell to include within Active Directory. Kerberos provides the following security features for an Active Directory domain:
Enforcement the mutual authentication process by using a ticketing system
The authentication process is handled primarily by the client, reducing the load on the servers
Domain controllers share the authentication load by running as Kerberos Distribution Centers (KDCs)
No portion of the password is ever transmitted over the network
Attackers are prevented from capturing and replaying packets from the network since the packets are time sensitive
How to Defend Against Weak Passwords and Hashes
You might think you're in the clear if your company runs Active Directory (and therefore uses the more secure authentication protocol of Kerberos). You would be only partially correct. There is one slight problem with this line of thinking: the operating system still generates the old LM and NTLM hash, just in case!
The old LM and NTLM hashes are stored and even sent across the network with every authentication that is performed. This exposes both the computer and the authentication traffic to gross security vulnerabilities.
The vulnerabilities come from the fact that the password hash from LM and NTLM are weak and well known, to the point that tools such as LC5 and RainbowCrack can break one of these hashes in minutes.
Since these protocols are weak and they are not used in most computer networks anymore, you can test eliminating them to see if your network still functions. Even if you are running Windows 95 clients, you can eliminate LM and NTLM. This is possible due to the _ Active Directory Client Extensions, _ a free download from Microsoft. These extensions enable Windows 9x (95, 98, and Me) and Windows NT 4.0 computers to use NTLMv2.
How do you eliminate, or at least protect against such password-breaking tools? There are solutions for both LM/NTLM and NTLMv2. You should have the IT staff test all of these settings in a small area of the production network first, to ensure they don _ t break any applications or network devices that rely on LM/NTLM authentication.
Steps for LM/NTLM Protection
Ideally, you will want to disable the use of LM/NTLM completely. This might not be possible if you have operating systems, applications, or network devices that are hard coded to use LM/NTLM for their authentication. Unfortunately, Microsoft did not turn this off by default and make you enable it if the authentication failed, but it is what we are stuck with. To protect your computers against the LM/NTLM vulnerabilities, do the following.
Step 1: Disable the Transmission of an LM Hash, Set Authentication Level
LM and NTLM password hashes are sent to every computer performing an authentication. This even occurs between a Windows Server 2003 domain controller and Windows XP Professional computer! To disable the transmission of the LM hash, you can configure a Group Policy object (GPO), as shown in Figure 1.
Once the policy is accessed for configuration, it will present six different settings that you can make for the LAN Manager authentication level, as shown in Figure 2.
These settings control both the client (users _ computer or server) and domain controller. The following list describes how each setting functions:
Send LM & NTLM responses: Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send LM & NTLM; use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLM response only: Clients use NTLM authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only/refuse LM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
Send NTLMv2 response only/refuse LM & NTLM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).
Notice that only the final setting eliminates both LM and NTLM. This is really the only secure setting from the list. If you allow the system to send the LM or NTLM password hash, an attacker can capture that information off of the network and crack it.
Step 2: Eliminate Hashes Stored on Local Computers
Another issue with LM and NTLM is that the password hashes are stored on computers by default. Again, this is for backward compatibility, even if the computer storing the password hash can support NTLMv2 and Kerberos. To eliminate this behavior, set a policy in a GPO, as shown in Figure 3.
To ensure that all LM hashes have been purged, all users will need to reset their password.
Step 3: Require Long Passwords
There are some environments that require LM and NTLM. If this is the case for your environment, then you can still reduce the exposure for those computers that don _ t use LM or NTLM. For those computers that support NTLMv2, you can require the users of these computers use a password longer than 14 characters. LM and NTLM can _ t create a hash for a password longer than 14 characters.
Steps for NTLM v2 Protection
All Windows 2000, XP, and Server 2003 computers use NTLMv2 and Kerberos. They will use Kerberos when functioning within an Active Directory domain and NTLMv2 when in a workgroup. So, it is really not a good idea to eliminate the use of NTLMv2. However, LC5 and RainbowCrack can still attack these hashes to compromise the password. To combat against these attacks, you can take one or more of the following precautions.
Step 1: Implement longer passwords in the domain and for local Security Account Managers (SAMs).
If the password is above 14 characters, LC5 and RainbowCrack have a harder time cracking the password. Really, when it comes to a password, longer is more secure. (I mention 14 here, so that is also negates the LM/NTLM hash).
Step 2: Force users to change passwords frequently.
You want to force users (domain and local) to change passwords often. If the password becomes invalid before the cracking tool can break into it, then the password is never compromised. Figure 4 shows where you can set password policies.
|
Figure 4. Account Policies control the password for domain users Click to enlarge |
There are suggested values to set these settings to help reduce the exposure of the password hash.
Maximum Password Age: 40 to 45 days
Minimum Password Age: 1 to 2 days
Enforce Password History: 12 to 24 unique passwords
Password must meet complexity requirements: Enabled
Step 3: Use passphrases
One of the latest trends initiated by Microsoft is to forget about using passwords. Instead, you should be using passphrases. A common password might be T$(!4b_%. This is very hard to remember and if it goes past 7 or 8 characters, becomes impossible to remember. However, if a passphrase is used, it is easier to remember. Here is an example passphrase:
I live in AZ where the temperature averages 100 degrees.
The benefits of using a passphrase include:
It meets password complexity requirements
It is easy to remember, much easier than a complex-7 character password
Long passphrases (this one uses 56 characters) can _ t be cracked by any tool existing today before the password is changed Conclusion
All companies must use passwords to protect user logon and resource access. The operating system tries to protect the password by encrypting it with a hash algorithm. However, the older authentication protocol hashes are not secure. Yet, the current operating systems continue to create and communicate the insecure hash for backward compatibility. This creates an enormous security vulnerability throughout the entire network, even if there are no legacy operating systems running.
Precautions must be taken to protect these password hashes. First, eliminating all use of LM/NTLM is a great step. There are many measures that you can take to do this. Then, NTLMv2 must be protected too. By far the best protection here is to use passphrases, not passwords. The current cracking tools are awesome, but not good enough to beat a 50+ character passphrase.
Additional articles by Derek Melber