Should you worry about password cracking?

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.


Comments (9)
  1. Anonymous says:

    OK. Let me get this perfectly straight. I am not going to give you a new way to do your passwords like

  2. Anonymous says:

    OK.  Let me get this perfectly straight.  I am not going to give you a new way to do your passwords…

  3. Mark Twain says:

    "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."


  4. What Mark? That wasn’t clear? 🙂

    What I meant was that if you disabled cached credentials users have to maintain two accounts, one local and one domain account. Given how good humans are at remembering passwords, there is a really good chance they will use the same password on both. If an attacker can access the cached credentials he can also access the local hash. The local hash is identical to the one stored on the domain and can therefore be used in a pass-the-hash attack against the domain directly. The cached credential is not usable in this way and must be cracked, which takes a while; about three times longer than cracking a regular password hash. Therefore, storing cached credentials is likely to increase security, not decrease it, since it allows users to use a much stronger credential verifier on the domain member when not connected to the domain.

    Does that clarify things for you? Send me a mail otherwise.

  5. Vic Pollard says:

    I’m intrigued that you think boiling down a phrase into something shorter is bad. Yes, I know pass phrases provide the strongest passwords and would never discourage their use. However, talking about regular end users, it’s hard enough to stop them using all the usual weak passwords (variations of "password", their names, names of family members, their dog, their football team) and telling them they need a thirty character pass phrase isn’t usually greeted with much enthusiam. Surely something which looks like a random mix of upper case, lower case and numbers is better than "passw0rd"?

  6. Certainly. Something that is seemingly random is better than a single word, or a single word, with a simple substitution. However, a phrase, which is meaningful, is much stronger still, is just as easy to remember, and only marginally harder to type. I’m not saying you need thirty characters. 10 – 15 or so is perfectly fine for many uses, and chances are most people can handle that. We obviously have to keep this realistic, and length is an important factor in that.

    BTW, the statistic that it is much easier to crack the short password derived from a phrase than the phrase it was derived from is real. I found this same advice in our internal password policy here at Microsoft. I fed the sample they used there into LC5 and cracked it using rainbow tables in 43 seconds. Since the phrase cannot be cracked by most current tools (and I won’t live long enough to see it happen even if it were possible technically) I calculated the crack time for that based on a brute force attack: 1,500,000 years! Even if you had a dictionary of words and a pass phrase cracker the crack time would be on the order of several thousand years. Obviously, cracking is not that meaningful, but as an order-of-magnitude comparison it is still valuable. This lends huge creedence to the argument that you should use the phrase itself, not the derived password.

    Frankly, I think this advice came out of the issue that in Windows 9x and NT 4.0 you could only use a 14-character password. In order to make those stronger someone came up with this idea, or at least adapted it. Today, with Windows 2000 and higher supporting 127 character passwords, this advice is simply outdated and wrong.

  7. Vern Buis says:

    Jesper, first, thanks very much for the help your provide via your columns! You mentioned service accounts and their passwords; I am also concerned about scheduled tasks. We have many that run backups and other maintenance, which I have tried (unsuccessfully so far) to move away from administrative accounts. Is there any way to run these under the Network Service account–if so, how do I enter it’s password? Are passwords for scheduled tasks vulnerable to cracking? Where and in what form are they stored?

  8. Vern, unfortunately, there is no way to run processes as Network Service under the task scheduler. That account is not a normal account in that sense of the word. You would be better off creating a limited account and run the task in that account.

    I believe the credentials for scheduled tasks are encrypted using the data protection APIs and then stored somewhere. Possibly they are in the LSA secrets, but I am not completely sure. The credentials are not really vulnerable to cracking the normal sense of the word, although anyone who can run code as the system (or an admin) can theoretically get them in cleartext by doing exactly what the task scheduler service would do to get them.

Comments are closed.

Skip to main content