Protect Against Weak Authentication Protocols and Passwords - LM/NTLM/NTLMv2/Kerberos

http://www.windowsecurity.com/articles/Protect-Weak-Authentication-Protocols-Passwords.html

Are you weak?

Microsoft has gone from very weak password authentication protocols to those that do a sufficient job in protecting the password. With new authentication protocols such as NTLMv2 and Kerberos, Microsoft provides a secure environment for protecting passwords within your organization.
The problem comes into play in that Microsoft still supports the legacy authentication protocols such as Lan Manager and NT Lan Manager. Although you won’t usually have computers on your network that support these older authentication protocols, they are still available on your Windows computers. To complicate the issues, in most environments, these authentication protocols are still hashing the password “just in case a computer only supports the older hash” is contacted. This poses severe security risks and opens up the computer to easy attacks.
Authentication Protocols
Microsoft has supported many authentication protocols over the years. Each time they release a new authentication protocol, it adds new features and security enhancements. Along the way, they also keep the legacy authentication protocol in the operating system to support the older computers that don’t support the latest and greatest authentication protocols. This legacy support forces the newest operating systems like Windows Server 2003 to support all Microsoft supported authentication protocols: Lan Manager, NT Lan Manager (both versions), and Kerberos.
The keys to decrypting all of these authentication protocols and features are really multi-fold. First, we must understand what each protocol provides, so make a good evaluation as to how useful it is for the environment. Second, it must be clear as to which operating system supports which authentication protocol. Even if an authentication protocol is weak, it might be required based on the operating systems running on the network. Third, if an insecure authentication protocol is necessary, the methods to protect the password, password hash, and overall network security must be understood.

Lan Manager

Lan Manger (LM) is one of the oldest authentication protocols that Microsoft has used. It was first introduced with Windows 3.11 and is not very secure. The features of LM are not very luxurious and you can quickly see that they pose many security risks just by reading the description of each.
The hash is case-insensitive.
The character set is limited to 142 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) was the predecessor to LM and was introduced with Windows NT 3.1. The reason that a new authentication protocol was required was that there was a new network directory service introduced with this version of the operating system. The new directory service was controlled by the domain controller. NTLM required that the domain controller store the hashed password for the domain user accounts. The features for NTLM are identical to LM, which shows that this protocol is just as weak as LM, it is just implemented a bit differently.

NTLMv2

NTLMv2 was not released with an initial operating system debut. It was released within Service Pack (SP) 4 of Windows NT 4. With the poor password protection of LM and NTLM, Microsoft fixed many of the issues that these older authentication protocols possessed. The features of NTLMv2 include the following.
Passwords can be up to 128 characters long.
Mutual authentication between the client and server.
Provides longer keys to produce the stronger password hash.

Kerberos

Kerberos is an industry standardized and approved authentication protocol. Kerberos is in its fifth version as defined in the Internet Engineering Task Force’s (IETF) Request For Comments (RFC) 1510. Microsoft has added some minor features to the Kerberos standard to take full advantage of the protocol in a Windows environment. The key features that Kerberos provides in an Active Directory domain include the following.
Kerberos enforces 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.

What Authentication Protocol does your OS support?

It might come as a surprise to you, but not every Windows operating system supports the most secure authentication protocol. This means that if you are running older operating systems, there is a chance that LM is still being supported and used on your network. This should make you feel a bit uncomfortable and uneasy about your overall network security. Here is a list of each OS and the authentication protocols that they support.
Windows 95, 98, and Me
Windows 9x, which includes Windows 95, 98, and Me, does not support NTLMv2 or Kerberos by default. Out of the box these operating systems only support LM and/or NTLM. Since most companies have a portion of the users still running on Windows 9x, this should make you pause and consider the situation at hand.
If you do nothing to fix the problem, your network is constantly storing and communicating the very weak LM password hash from computer to computer. To fix this issue, you can install the “Active Directory Client Extensions” on your Windows 9x computers. This will immediately allow them to support NTLMv2. There is nothing that can make a Windows 9x computer support Kerberos. To obtain the “Active Directory Client Extensions”, download the installation file from:
http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/adextension.asp

Windows NT

As we have already seen, Windows NT rolled out supporting NTLM. Then, in SP4 for Windows NT 4.0, Microsoft introduced support for NTLMv2. The “Active Directory Client Extensions” would also give the Windows NT computers support for NTLMv2, as well as the other benefits for communicating with the Active Directory domain.

Windows 2000/XP/2003

Windows 2000, XP, and Server 2003 come standard with support for all authentication protocols that Microsoft supports: LM, NTLM, NTLMv2, and Kerberos. These computers will use Kerberos when they are communicating with Active Directory and the members of Active Directory. When these computers are in a workgroup, they will use NTLMv2. The LM and NTLM are supported and used when communicating with legacy operating systems that only support these old weak protocols.

Defeating Weak Passwords and their Hashes

If you have been living under a rock for the past 10 years, you might not have heard of the common tools used to crack into a Windows password hash. These tools are LC5 (L0phtCrack) by @Stake (http://www.atstake.com/) and RainbowCrack (http://www.antsight.com/zsl/rainbowcrack/).
The two tools are very different from one another in how they approach cracking a password hash to obtain the password.
LC5 takes the “brute-force” method to attack the password hash. This requires processing power and time. The tool attacks the password hash to try and decode the hash and determine the original password. LC5 does support hash tables like RainbowCrack, but the vendor does not recommend hash tables for more than 2500 user accounts.
RainbowCrack only works with pre-computer hash tables. These tables are stored on large hard drives and can take up TBs of space. The tables are the actual hash of every combination of the character set for any given length password. Since the hash is already known, the tool only needs to do a comparison of the hash table to the password hash from the operating system. This provides a faster method of cracking the password, approximately 1/10th the time as a brute-force attack.
With these tools being cheap, easy to use, and efficient, it is up to everyone to protect the passwords for your company and computers. The following are suggestions on how to protect passwords for the different authentication protocol hashes.

LM/NTLM protection

If possible, you want to eliminate all use and consideration of LM and NTLM on your network. It is a shame, but all computers support LM and NTLM by default. This does cause a large security vulnerability on your computers and network as a whole. Here are some measures you can take to protect your computers with regard to LM and NTLM hashes.
By default the LM and NTLM password hashes are sent across the network during authentication. This occurs even when a Windows XP client authenticates to a Windows Server 2003 domain controller! To disable this, configure the Group Policy Object (GPO) shown in Figure 1. Don’t allow the LM and NTLM hash to be transmitted across the network.
Figure 1: Lan Manager Authentication levels using a GPO
Once you open this policy for configuration, you will be presented with six possible settings, as shown in Figure 2.
Figure 2: Possible Lan Manager settings
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).

The first four options are not doing anything to reduce the use of LM and NTLM. If possible, these settings should not be used. Ideally, the final setting will be used for all computers in the enterprise to reduce the use of the LM and NTLM hashes.
Another configuration is done to prevent the LM and NTLM hashes from being generated. The LM and NTLM hashes are generated by all computers by default to support backward compatibility, even if there are no computers on the network that require LM or NTLM hashes. This is also a GPO setting, as shown in Figure 3.
Figure 3: LM hash storage control using a GPO
This setting does not take immediate affect. Rather, it will not store the LM hash when the password is changed.
If there are computers, applications, or devices that still require LM or NTLM, you can still bypass the creation of the hash by using a password that exceeds 14 characters. Once the password goes to 15 characters, the LM and NTLM hash is not stored because it relies on a 14 character password. Of course, for those users and applications that need LM, they will still need to obey the 14 character limit.
NTLMv2 protection
It is impossible to eliminate the use of the NTLMv2 authentication protocol, since it is needed for workgroup environments on Windows 2000 and greater operating systems. However, there are measures that you can take to protect an attacker from cracking these hashes.
The longer the password the better. Even rainbow tables fall short when the password reaches 15 or more characters, due to the amount of storage required to store the pre-computed hash tables.
Force users to change passwords often. This is done for domain user accounts in the Default Domain Policy, as shown in Figure 4.
Figure 4: Account Policies control the password for domain users
The following is a list of the key settings for the Account Policies and the suggested settings to protect passwords and their hashes.

“Maximum Password Age” – 40 to 45 days

“Minimum Password Age” – 1 to 2 day
“Enforce Password History” – 12 to 24 unique passwords
“Password must meet complexity requirements” – Enabled

A new approach that is catching the attention of everyone is to use passphrases instead of passwords. It is infinitely clear that a password such as @3*()!b& is not easy to remember. If you have to come up with a password this complex every month, you are bound to write it down. So, instead of using a password, use a passphrase like:

I live in AZ where the temperature averages 100 degrees.

The benefits of using a passphrase like this include:

It meets password complexity requirements.
It is easy to remember, much easier than a complex-7 character password.
This passphrase can’t be cracked by any tool existing today before the password is changed. Even if the password age is pushed to 90 days, LC5 and RainbowCrack can’t break the code in this short of time.


Summary
Everyone must use passwords to protect network resources. The operating system must also protect these passwords by encrypting them using a password hash. Some password hashes are very insecure and can cause immediate vulnerabilities to the computer and network. Other password hashes, like NTLMv2, add new features that help protect the password hash, but if the password is not long enough, the password hash can be decrypted quickly.
It is up to network admins, security pros, and each user to take actions to protect passwords and hashes. Making passwords longer can go a long way to beating these crack tools. Also, eliminating LM and NTLM where possible is a great step to securing the network. Finally, the use of passphrases instead of passwords will instantaneously cripple the current crack tools to where they will never crack a production password.