Talk to a Security Expert Now: (800) 721-9177

Disable Storage of the LM Hash

The LM hash is a horrifying relic left over from the dark ages of Windows 95. Also known as the LanMan, or LAN Manager hash, it is enabled by default on all Windows client and server versions up to Windows Server 2008 where it was finally turned off by default (thank you Microsoft).

So what’s wrong with the LM hash? Lets look at exactly how the LM hash is computed, via Wikipedia:

  1. The user’s ASCII password is converted to uppercase.
  2. This password is null-padded to 14 bytes.
  3. The “fixed-length” password is split into two 7-byte halves.
  4. These values are used to create two DES keys, one from each 7-byte half, by converting the seven bytes into a bit stream, and inserting a null bit after every seven bits (so 1010100 becomes 01010100). This generates the 64 bits needed for a DES key. (A DES key ostensibly consists of 64 bits; however, only 56 of these are actually used by the algorithm. The null bits added in this step are later discarded.)
  5. Each of the two keys is used to DES-encrypt the constant ASCII string “KGS!@#$%”, resulting in two 8-byte ciphertext values. The DES CipherMode should Set to ECB, and PaddingMode should set to NONE.
  6. These two ciphertext values are concatenated to form a 16-byte value, which is the LM hash.

If your eyes glazed over reading that, that’s ok. Basically two major bad things happen when Windows computes the hash:

  • The password is first converted to all uppercase.
  • The password is split into 2 different 7 byte chunks, which can be attacked separately.

Due to these weaknesses in the hashing process, and the prevalence of the time-memory tradeoff attack using Rainbow Tables, it is possible to crack nearly all LM hashes in a matter of seconds or minutes. If a bad guy gets a hold of your hash file and it’s stored as LM you’re pretty much screwed. This is made many times worse if that hash file is from a domain controller as it then contains the passwords for every user in your organization.

Thankfully disabling the LM hash isn’t that hard. On your domain controller navigate to Start>Administrative Tools>Group Policy Editor>Computer Configurations>Windows Settings>Security Settings>Local Policies>Security Options. From here Scroll down to the “Network security: Do not store LAN Manager hash value on next reboot” setting and set it to Enabled.

Caveat emptor: although you’ve disabled the storage of the LM hashes, it doesn’t actually take place until users next change their password. If passwords aren’t changed after this setting is enforced, this is a moot point. I’ve seen environments that have this setting enabled but 90% of their passwords are still stored as LM because passwords are set to never expire, and users are never required to change their password. Once this setting is enabled, it’s not a bad idea to force a domain wide password reset.

Now’s the time to make sure you’ve set a decent maximum password age setting.

This Post Has One Comment

  1. Windows 2008 R2, “Network security: Do not store LAN Manager hash value on next reboot” is used and LM is available, mimikatz shows password as plaintext. Password was changed few times after server deployment.
    Windows 2012 R2, LM is missing in mimikatz output and password as plaintext is not visible.
    //Petr

Leave a Reply

Your email address will not be published. Required fields are marked *