I have received more and more queries about whether to worry about password cracking, and what to do to avoid it. It seems it may be time to document this a bit better. It is all, of course, already in Protect Your Windows Network, but in the October TechNet Security Newsletter I have a column on Frequently Asked Questions on passwords, which addresses this, along with several other issues. I thought it might be interesting to have a little debate or take comments about the newsletter piece in this forum. Here is an excerpt that deals with password cracking:

Should I be concerned about password cracking?

The answer is a qualified no. Cracking against captured hashes is not an interesting attack. The hash is the only secret used in challenge-response protocols today both on Windows and on other operating systems. An attacker with the hash has all that is required to authenticate as the user and cracking is simply a waste of time. Tools that implement this type of attack, known as a pass-the-hash attack, are available on the Internet already. Although the tools are still relatively unstable and unreliable, we should expect their quality to improve significantly as passwords get better. In addition, in order to capture the hashes the attacker must break into the authentication server, which is typically the domain controller on a Windows-based network. If this has occurred, the network has been fully compromised already and cracking passwords is only useful to attack other networks where the same users used the same password (a practice that should be strongly discouraged). Windows will never pass the hashes across the network in an unencrypted channel. Thus, capturing the hashes in a network transfer is pretty unlikely.

Since January 2005, cracking against the stored password verifier (the cached credential) has received renewed interest due to the publication of the first commonly available tool to extract those verifiers from a compromised computer. Cracking the password verifier is reasonably efficient, taking roughly three times longer than cracking against the NT hashes. This, however, is really not an interesting attack either. First, the verifier is a hash of a hash, making it at least twice as resilient as the original hash. Second, since the password verifier is salted with the username it is unique even for two users using the same password. While a pre-computed hash attack can still be used to speed up the first computation, it is useless against the second hash. Finally, the password verifier serves a very important purpose. Without it users would have to use local credentials when logging on to a computer while disconnected from the domain but use domain credentials when connected. Clearly this process would create a nuisance for users. More important, however, is the effect it would have on the captured hashes. Most security researchers would agree that a vast majority of users would use the same password for both accounts. If an attacker compromises a computer that has local credentials and those credentials match credentials on a domain, the attacker would now have all the information needed to authenticate as the user to the domain and would not have to crack a single password. The OWF representation stored locally for the local account is identical to the one stored for the user’s domain account if the two have the same password. Clearly the dynamics of the human-computer interaction mean that the password verifier probably increases security instead of decreasing it. Therefore attacks against the password verifier are probably also not interesting.

Cracking against captured challenge-response pairs is, however, still an interesting attack. However, using the LM Compatibility Level switch it can be effectively invalidated by not transmitting the LanMan challenge-response pairs. This is a valid approach in almost all environments. Some (quite possibly not all) problems with LMCompatibilityLevel were listed above. If you are not subject to any of those issues, we recommend that you configure LMCompatibilityLevel to 5.

Update October 13, 2005:

Normally I do not like updating blog posts, but I just got a link to this horrible piece of bad password advice from my friend Dick Carlson and could not pass it up. See how many individual pieces of bad advice you can find in this piece. I particularly like this piece:

Boil down a memorable phrase or quote into a string of upper- and lowercase letters, numbers and special characters. For example, "Easy for you to say" becomes Ez4U2Say.

Good idea! Let's take a nice long and strong pass phrase that would take about 800,000 years to crack or guess and turn it into a crappy pasword with almost no entropy that would crack in about 18 seconds and guess in not much more.