I recently came across a number of sources that suggest that cracking Windows user account passwords is easy by examining their password hashes.

I understand that these hashes are stored in the SAM file in two formats: LM and NTLM. LM is unsecure (and since Vista, a meaningful one isn't stored, right?). However, NTLM is also cryptographically weak, and can also be broken disturbingly quickly.

In any case, even with what I would consider "strong" passwords, I have seen them cracked in a matter of a few minutes--simply by rebooting the computer into Linux from a flash drive, and then running a program that extracts passwords from the hashes. This seems to me to be a huge vulnerability.

About the only thing I was able to find online about preventing this was to use a longer password, so as to guarantee that the weaker LM hash isn't meaningful--but NTLM is still weak.

Anyone know how to protect against these sort of attacks?

  • 2
    Bitlocker fulldrive encryption prevents from booting from linux and extracting password. Secure bios should prevent loading alien linux kernel. Commented Jul 25, 2012 at 22:27
  • @AndrewSmith yeah, I would just have to pull the disk data lead and plug it into my lappy instead to get over UEFI secure boot... Bitlocker, bah, I'll just do a cold boot attack.
    – ewanm89
    Commented Jul 25, 2012 at 23:23
  • See this link and disable booting from USB and CDs - security.stackexchange.com/questions/11023/… ...also, if a password was bruteforced (presumably) in a few minutes, it obviously wasn't strong. Make sure to include special characters, numbers, caps and lowercase in combination.
    – cutrightjm
    Commented Jul 26, 2012 at 14:24
  • Doesn't matter. Just use the hash itself: security.stackexchange.com/questions/168940/…
    – SDsolar
    Commented Sep 7, 2017 at 2:52

3 Answers 3


There’s a few things to consider here. Two algorithms have been used by Microsoft for the accounts database on windows systems:

LM (LAN Manager)

NTLM (NT LAN Manager)

An attacker with physical access to your system can pretty easily dump the contents of the SAM (Security Accounts Manager) database for all local accounts and then use something like Ophcrack (http://ophcrack.sourceforge.net ) to run rainbow table attacks against the hashed values.

However, you need determine what the actual risk is: the attacker is able to crack the password and/or the attacker is able to access the system. This is important because it’s not necessary to crack the password (guess it’s value) in order to compromise the system. Many other tools simply replace the hash in the SAM database with something chosen by the attacker. This compromises the system, but not necessarily the password itself. Whole disk encryption solves both problems as a first line of defense: your attacker is unable to mount the volume in whatever tool they’re using to muck around in the SAM database. If you go this route a lot of commercial vendors offer solutions. Truecrypt (http://www.truecrypt.org/) offers a superb free program. Bitlocker or any OS-integrated encryption solution is pretty much worthless since they are readily susceptible to cold boot attacks.

One of the newer solutions are self-encrypting drives that require a boot into their own firmware for access.

  • "TrueCrypt stores its keys in RAM; on an ordinary personal computer the DRAM will maintain its contents for several seconds after power is cut (or longer if the temperature is lowered). Even if there is some degradation in the memory contents, various algorithms can intelligently recover the keys. This method, known as a cold boot attack (which would apply in particular to a notebook computer obtained while in power-on, suspended, or screen-locked mode), has been successfully used to attack a file system protected by TrueCrypt"
    – Ramhound
    Commented Jul 26, 2012 at 11:06
  • 1
    I wouldn't say that Bitlocker is "worthless" otherwise why would Microsoft even implement it? If Bitlocker is susceptible to cold boot attacks then TrueCrypt is also. The problem with making statements that make your bias clear, is that most often times, those statements are 100% false. The built in encryption that exists in iOS, Mac OS, and Microsoft Windows performs the exact same function as TrueCrypt and is susceptible to similar attacks ( all except iOS because of the hardware it uses ).
    – Ramhound
    Commented Jul 26, 2012 at 11:09
  • 1
    I think a few of these comments have also made it seem like a complete script kiddie attack to use cold boot; researchers in a lab are one thing, but if you blow it in the real world, you might only have one chance, its not a guarantee. Again you need to be targeted by someone who can get physical access and is technical. With those resources, they will probably just attack you, the human, at a lower cost per attack attempt.
    – Eric G
    Commented Jul 26, 2012 at 18:04
  • @Eric G as regards physical coercion, TrueCrypt implements a decoy OS feature meaning that in the event of extortion one can provide access to seemingly sensitive but relatively worthless information.
    – deed02392
    Commented Dec 6, 2012 at 8:22
  • @raz: NTLMv2 is the authentication protocol, not a separate hashing format. This answer should only list the first two. Commented Jul 14, 2015 at 14:16

In all of this answer, I am considering the problem of recovering the password (or an equivalent password) from a purloined hash, as stored in a server on which the attacker could gain read access.

The NTLM hash is weak, but not as weak as the older LM hash.

The older LM hash includes several capital weaknesses:

  • Not case-sensitive.
  • Limited to 14 characters.
  • Splits the password in two 7-character halves which are hashed separately.

This last weakness allows for very efficient cracking (regardless of the care taken in choosing the password); see this answer for a some details.

The less-old NTLM is just MD4 computed over the password. This time, the password is case sensitive, and can be quite long. There is some dispute as to the real maximum password length which could apparently be up to 127 characters or so. Since MD4 is computed over UTF-16 encoding of the password, the whole range of Unicode could theoretically be used, but since the user needs to type the password regularly (and without visual feedback), using characters beyond the printable ASCII set is looking for trouble.

What is weak in NTLM hash is that it is unsalted, and that MD4 is fast (MD4 is also cryptographically broken in several ways, but not for raw preimage resistance as is used for password hashing; for that, MD4 is as robust as it ever was). MD4 is actually faster than MD5. A recent GPU will compute several billions of MD4 instances per second. This makes it easy for the attacker to explore vast sets of potential passwords (what is known as a dictionary attack). The only defense is to choose your passwords from an even vaster set.

Let's throw some maths at it: since NTLM is unsalted, a dedicated group of attacker might find it worthwhile to build a big rainbow table. There are various possible optimizations, but, as a rule, things would go like this:

  • There is a security parameter, called t; that's the average length of a chain in the rainbow table.
  • If the set of passwords covered by the table has size N, then the storage requirements are about 10*N/t bytes (10 bytes per sorted chain end is a reasonable estimate).
  • Building the table entails a cost of about 1.7*N hash function invocations.
  • Attacking one password with the table entails computing about t2 times the hash function, and making t lookups in the table.

If the table is split over a hundred mechanical hard disks, then about 10000 lookups can be done per second. If the attacker is really motivated, he might wish to spend one hour or so per password, which means a maximum t of 3600000 for the lookups (let's say 222); the corresponding CPU cost is down to about 232 hashes per second, which is feasible with a couple recent GPU. The hundred disks allow for 300 TB storage (I am talking about 3 TB disk, which are off-the-shelf today), which brings the possible N to about 267. That's rather huge, but technologically feasible. Our group of attackers could buy a hundred GPU (and a big air conditioning unit) and be done with computing that table within a few months.

So, in order to defeat our motivated adversaries, we need to choose passwords at random from a set bigger than their N. If our set of possible passwords has size more than 277 and our passwords are chosen randomly and uniformly in that set (i.e. the password entropy is 77 bits or more), then the attacker has only 1/1000 chance of cracking a given password with his table. This ought to be sufficient to dissuade him.

How do we get 77 bits of entropy ? If we restrict ourselves to letters (uppercase and lowercase) and digits, so that the password can be typed on arbitrary keyboards, then we can have a little less than 6 bits of entropy per character. Therefore, 13 characters are sufficient. Isn't it swell ? Only 13 ! No need to go to huge passphrases. But mind the small type: that's 13 totally random letters or digits. No question of letting a human choose these characters, or even generating a dozen passwords of 13 characters and letting him choose the one he likes best. You take the generator, you produce one password, and you learn it. The mental effort is the price of using an unsalted fast password hashing mechanism like NTLM.

(Of course, the attacker group described above is realistic. You may want to increase complexity a bit, so that your passwords will also be strong with regards to tomorrow's attackers; so make it 14 or 15 characters to be safer.)


In general, on most systems a longer password is always better.

There are of course rainbow tables for NTLM (e.g., http://www.freerainbowtables.com/en/tables2/)

From a brute forcing perspective though, you should be limiting the number of failed login attempts before you are locked out. This can be set using local policy. 3 failed attempts, then you block them.

Physical security trumps all. Block BIOS from booting a cd or usb and put a lock on the box. Of course, I reiterate the comment above, use full disc encryption, maybe even multifactor. You can't mount an encrypted drive in Linux magically, you need to know the password and/or key.

Cold boot and evil maid require someone to really invest time in breaking your machine. On your local home pc, its must more likely you'll get tricked into downloading malware or that you have unpatched software and they will just get root (ahem, administrator) and not care about breaking your password.

If you have real secret stuff, do full disk encryption and put the important stuff it a second level encryption container.

I once heard an only computer guy say that the only secure computer is one that has bit chopped up with an ax and then burned. :-)

  • You should also set the registry to disable LM (isn't that disabled be default in vista and higher?)
    – Eric G
    Commented Jul 25, 2012 at 23:59
  • Cold boot is not that difficult, you extract the key with no issues directly from RAM. Commented Jul 26, 2012 at 0:57
  • It sounds like a home situation, someone still has to get into your house/apartment first.
    – Eric G
    Commented Jul 26, 2012 at 3:23
  • For the passers-by, more on the cold boot: static.usenix.org/event/sec08/tech/full_papers/halderman/…
    – Eric G
    Commented Jul 26, 2012 at 3:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .