The LMHash, also known as the Lan Manager hash, is technically speaking not a hash at all. It is computed as follows:
1. Convert all lower case characters in the password to upper case
2. Pad the password with NULL characters until it is exactly 14 characters long
3. Split the password into two 7 character chunks
4. Use each chunk separately as a DES key to encrypt a specific string
5. Concatenate the two cipher texts into a 128-bit string and store the result
As a result of the algorithm used to generate the LMHash, the hash is very easy to crack. First, even a password longer than 8 characters can be attacked in two discrete chunks. Second, the entire lower-case character set can be ignored. This means that most password cracking tools will start by cracking the LMHashes and then simply vary the alpha characters in the cracked password to generate the case-sensitive passwords. Note that in order to log on to a Windows 2000 system, whether remotely or locally, you will need to use the case-preserved password.
The NTHash is also known as the Unicode hash, because it supports the full Unicode character set. The NTHash is calculated by simply taking the plaintext password and generating an MD4 hash of it. The MD4 hash is then stored. The NTHash is much more resistant to brute force attacks than the LMHash. Brute forcing an NTHash takes several orders of magnitude longer than brute forcing the LMHash of the same password.
What constitutes a good password?
There are some general guidelines for what constitutes a reasonable password:
* Longer than 7 characters (otherwise the second half of the LMHash is an encryption using the NULL password
* Contains elements from at least three of the following four character sets
o Uppercase characters
o Lowercase characters
o Non-alpha numeric characters
* Does not contain any part of the users name, username, or any common word
This complexity is enforced via a password filter, and can be optionally required using group policy. Additionally, an administrator can customize the complexity requirements by writing a custom password filter. Such a filter could, for example, enforce that company names are not part of the password, or require additional complexity. For more information on how to write such a filter, refer to section on Password Filters in the Microsoft Windows Software Development Kit, at http://msdn.microsoft.com/library/en...rd_filters.asp
However, most passwords like these are still easily cracked. There are several steps that can be taken to make a password harder to crack
* Use non-alpha numeric characters other than those from the "upper row." Upper row characters are those you type by holding down SHIFT and typing any number key. Most password crackers know that the upper row characters are the most common method to add entropy to a password and therefore start cracking with those.
* Use ALT characters. ALT characters are those that you type by holding down the ALT key (the FN+ALT keys on a laptop) and typing a three or four digit number on the numeric keypad (the numeric overlay keypad on a laptop). Most password crackers are not capable of testing the vast majority of ALT characters.
* Do not allow storage of the LMHash.
There are many ways to prevent storage of the LMHash. A system wide method will be discussed later in section Error! Reference source not found.. However, the creation of an LMHash can be controlled on a per-account basis by constructing the password in certain ways.
First, if the password is longer than 14 characters, the system is unable to generate an LMHash. In Windows 2000, passwords can be up to 127 characters.
Second, if the password contains certain ALT characters, the system will also not be able to generate an LMHash. This latter point is tricky, because while some ALT characters significantly strengthen the password by removing the LMHash, others significantly weaken it since they are converted into a normal upper-case letter prior to storage. There are many characters, however, which will strengthen the password. Table 1 lists all the characters below 1024 which cause the LMHash not to be generated.
Table 1 ALT characters which cause the LMHash to disappear
0128-0159 0306-0307 0312 0319-0320
0329-0331 0383 0385-0406 0408-0409
0411-0414 0418-0424 0426 0428-0429
0433-0437 0439-0447 0449-0450 0452-0460
0477 0480-0483 0494-0495 0497-0608
0610-0631 0633-0696 0699 0701-0707
0709 0711 0716 0718-0729
0731 0733-0767 0773-0775 0777
0779-0781 0783-0806 0808-0816 0819-0893
0895-0912 0914 0918-0919 0921-0927
0929-0930 0933 0935-0936 0938-0944
0947 0950-0955 0957-0959 0961-0962
In many environments the LMHash cannot be disabled system wide. This could be the case, for example, in environments where the operating system is installed over the network by booting to a DOS disk. DOS does not support the NT hash algorithm and therefore requires the LMHash to be present. DOS also does not support ALT characters in the password. While we recommend that LMHashes be disabled system wide in all environments where it is feasible, the above techniques can be used to strengthen individual passwords in all environments.
We particularly recommend using ALT characters on sensitive accounts such as service accounts and administrative accounts. In general, these accounts need greater protection than ordinary user accounts, and the users using them should be willing to use very complicated passwords. One caveat is that using ALT characters in a password does break the recovery console, however. This should be kept in mind before setting up passwords with ALT characters.