The vulnerability of Windows passwords to table based cracking.
The vulnerability of Windows passwords to pre-computed table based cracking:
This write up discusses the inherent weaknesses of the default windows password scheme and how to remediate that weakness by editing your system settings.
Recently the issue of password strength and auditing came up and the discussion prompted me to do further research into the subject. What I found is that the critical vulnerability with windows passwords comes from the LM and NTLM algorithms it uses and the way Microsoft implements this with challenge response to authenticate users.
A lot of other people have covered this subject in great detail so I’ll just touch on it briefly here.
To test the information given below download the pwdump2 or pwdump3 programs and the “Ophcrack” time-memory trade off (table based) password cracker. Use the large pre-computed tables to run your tests on the hashes recovered by the pwdump programs.
Even though Active Directory may be used to enforce password complexity settings (upper, lower, alpha-numeric) the LM method re-designates all characters to upper case before the hash is computed, therefore, PaSswOrD is hashed as PASSWORD. Additionally, any password 14 characters or less is hashed and then divided into two seven character pieces, these smaller pieces are easily cracked using the time-memory trade off method. The MD4 hash of NTLM is a bit more robust but is still easily cracked. The addition of special characters to the aforementioned LM password is mostly irrelevant as the bulk of the password is cracked almost immediately and the remaining iterations don’t take long to complete.
The MD4/LM/NTLM hash is easily cracked (within a few minutes usually) and this leads to two attack vectors which are commonly exploited.
- Accessing and cracking the LM/NTLM hashes either on the host or on the domain controller and copying them off to be cracked.
- Sniffing the LM/NTLM authentication challenge/response pairs off of the network and then reassembling them to be cracked.
Microsoft has addressed this issue by implementing NTLMv2 authentication which is 128 bit and significantly more difficult to crack when good password generation practices are used. NTLMv2 is native to Windows 2000 domains greater than Service Pack 2.
With this in mind there are three changes that can be made to remediate this threat, they are:
- Disable LM/NTLM challenge/response authentication.
- Enable NTLMv2 authentication.
- Restrict the storage of LM/NTLM password hashes locally (client and server).
The LM/NTLM hashes currently stored on the domain controllers will be flushed the next time an authenticated domain user changes their password and will not be replaced with an NTLMv2 hash. If these methods are implemented I believe the need for manual password auditing is nullified.
The following pages document how to accomplish all three of the remediation methods above and provide links to addition information on the subject.
Restrict MS Active Directory to NTLMv2 authentication only and disable LM/NTLM:
The following steps are needed to disable LM and NTLM challenge/response authentication between Active Directory members and Domain Controllers.
On the domain controller open the domain security policy for editing and select the following settings:
- Locate the “LANMAN authentication level setting at, “Windows Settings/Local Policies/Security Options and open it for editing.
- Select “Send NTLMv2 response only\refuse LM & NTLM.
- Go to the action menu and select Reload to reload the AD Policy.
- Exit the Domain Security Policy Editor.
Only one policy change is necessary, the AD Policy change will migrate through the Domain Controllers on it’s own in a matter of minutes.
Restrict the storage of LM and NTLM hashes on MS Active Directory members:
To disable the storage of LM hashes in Win2k AD you must add a registry key to the registry on each Domain Controller and reboot the server. These settings will be passed to the AD members by group policy.
Link to the full article involving the restriction of LM/NTLM hash storage on MS AD members is (MS Article ID: 299656):
Windows 2000 SP2 and Later, this registry edit is for Windows 2000 SP 2 machines and later. It is not tested on machines prior to Win2k SP2. Windows 98, SE and ME machines require a special registry edit that is discussed in the linked article.
To make the registry edit on a Win2k DC do the following:
- Start the registry editor.
- On the Edit menu click “add key, type “NoLMHash and press enter.
Close regedit and reboot the Domain Controller.
Compatibility with Windows NT 4 and Win 98, 98SE and ME:
There are compatibility issues with Windows 2000/2003 Active Directory authentication and NTLMv2. These issues can be resolved through editing the registry on these older operating systems to enable NTLMv2 compatibility.
Details regarding Windows NT 4 workstation can be found here (software):
And here (how-to):
Active Directory Services In Windows 98, 98SE, ME:
Managing NT and 9x clients with Active Directory:
Here is a rundown of the features in the Active Directory Client Extensions patch:
- The ability to log onto domain controllers: This includes the ability to change passwords on any Windows 2000 domain controller in the domain, rather than just the primary domain controller for that domain (as was the case with NT 4.0 domains). Note that NT 4.0 clients and Win9x clients will only be able to change their passwords at the PDC; you can’t override NT 4.0 password behavior by changing the password at the PDC with this patch.
- Windows Address Book (WAB) properties: This allows users to search for and change the properties of user objects in AD through the Start -> Search system, and also allows for new schema elements to be added to said user objects through the client (in the event they are needed).
- NTLM version 2 authentication: Clients with the patch can perform NTLM v2 authentication over the network as well as version 1. Some of the changes in version 2 include encryption and hashing of the password, case-sensitive passwords, and a number of other changes for security.
- The DFS fault tolerance client: This allows clients transparent access to Windows 2000 distributed file system (DFS) shares, as well as failover shares described through Active Directory.
- Active Directory Service Interfaces (ADSI): This allows Active Directory actions to be scripted (through the use of Windows Script Host or other scripting systems), and allows programmers a common API to Active Directory functions.
Additional in-depth information regarding this process is available at the following URL’s:
Microsoft Tech net:
Restricting LM NTLM:
Selecting Strong Passwords:
The SANS Top 20, regarding section W3.1 Windows Authentication: