Disable Storage of the LM Hash
So what’s wrong with the LM hash? Lets look at exactly how the LM hash is computed, via Wikipedia:
- The user’s ASCII password is converted to uppercase.
- This password is null-padded to 14 bytes.
- The “fixed-length” password is split into two 7-byte halves.
- 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.)
- 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.
- These two ciphertext values are concatenated to form a 16-byte value, which is the LM hash.
- The password is first converted to all uppercase.
- The password is split into 2 different 7 byte chunks, which can be attacked separately.
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.
No comments:
Post a Comment