LM de-emphasized, NTLMv2 emphasized in Vista

Vista introduces a rather new but good authentication method for your network security, so says Mark Minasi. Check out this latest excerpt from his book, "Administering Windows Vista Security: The Big Surprises."

Windows Vista's little surprises
By Mark Minasi

Have a look inside Windows security guru Mark Minasi's latest book, Administering Windows Vista Security: The Big Surprises, with this excerpt from Chapter 1, "Administering Vista Security: The Little Surprises."

Vista changes two items in Security Options in a way that I personally like a lot, but I want you to understand what they might do to your network compatibility. The two settings are:

  • "Network security: Do not store LAN Manager hash value on next password change" is now enabled, even though it had been disabled by default until now.
  • "Network security: LAN Manager authentication level" changes from "Send LM and NTLM" to "Send NTLMv2 response only."

Vista security extras
Windows Vista's little surprises - Excerpts from Mark Minasi's latest book

Windows Vista: Inside the new security features

First, a little background. It's nice that we've got machines called domain controllers (DCs) that centrally store usernames and passwords so that every machine doesn't have to carry around a complete list of all usernames and passwords. But having central logon services means that you've got to figure out how to use those services safely. I say that because if I'm sitting at Workstation A and offer it my domain name and password, then how's Workstation A going to ask Domain Controller B to verify it? It's not a very good idea to ask across the network, "Hey, Domain Controller B, I've got a guy here who says he's a guy named Mark with password 'swordfish,' does that sound right?" It'd be a bad idea because people can easily listen in on network traffic.

So, instead of making DCs and workstations reveal secrets across the wire, Microsoft and other vendors do something a bit more crafty. When the workstation says to the DC, "I want to log Mark in, can you verify that this is indeed Mark talking to me," the DC replies "okay, I know Mark's password, and you've got the password that the would-be Mark offers. So here's a big random number. Take it and encrypt it, using the password that this might-be-Mark guy offered. Then send the encrypted result back to me." The workstation takes the random number (which is called the challenge), encrypts it with offered password, and sends that encrypted number (which is called the response) to the DC. Meanwhile, the DC also encrypts the challenge, using the password that it has on file for Mark. If the response from the workstation matches the encrypted challenge, then the DC knows that the password typed in to the workstation is indeed the correct one, without the workstation having to transmit the proffered password.

Now, that's just the broad outline of how this kind of authentication method, called a "challenge-response mechanism," works. The devil's in the details: complex encryption's hard to crack (and that's good) but requires more CPU power, long keys are harder to crack but also require more CPU power and make logons slower (and that's bad), so the OS vendor has to weigh its choice of encryption methods and key lengths carefully. As time has gone on, Microsoft has created three different challenge-response mechanisms: the late 1980s offered "LM," short for "LAN Manager," which was replaced in the early 1990s with "NTLM," the NT version of the LAN Manager logon protocol, and in the late 1990s Microsoft created a far better challenge-response mechanism called "NTLMv2." There's also Kerberos, an authentication method used most in the time in Active Directory, and that appeared with Windows 2000 in early 2000. But even a network with the most state-of-the-art stuff will sometimes fall back from Kerberos to either LM, NTLM or NTLMv2. That's not really a wonderful thing, as Kerberos is considerably more secure than the other three, but there is no way to banish the "LM family" altogether. But if you want to keep your network secure, then it'd be best to ensure that if Kerberos isn't available then your systems should use NTLMv2 rather than the older, less secure challenge-response mechanisms.

If NTLMv2's been around for nearly 10 years, why aren't we all using it now? Why hasn't LM and NTLM been banished for years? It's the same story as before: compatibility. If you've got some older computers in your network (Windows 9x, for example), then it's some work getting them to talk NTLMv2; MS-DOS systems and Windows for Workgroup systems will never talk NTLMv2. Alternatively, if you've got third-party network-attached devices like some of the Network Attached Storage (NAS) boxes like, for example, an old Quantum Snap Server, then a device like that might not understand NTLMv2.

Every modern copy of Windows knows how to log on using either the LM, NTLM, or NTLMv2 challenge-response methods, but which of those methods does it choose? You configure that with a setting in Security Options, "Network security: LAN Manager authentication level." By default an XP box will, when offered a logon challenge, compute two responses: the LM and NTLM response. As both of those responses are encrypted with an encryption algorithm that has been cracked in the past and gets easier to crack with every passing year as CPUs get faster, automatically responding LM and NTLM responses becomes less and less ideal all the time. Vista's default is different, and by default it offers the NTLMv2 response.

Will this new default cause you trouble? Well, any 2000, XP, 2003 or Vista system acting as a server can understand and use an NTLMv2 response, so if your Vista clients always produce NTLMv2 responses then you'll probably be okay. But, again, check your network-attached devices, like those convenient little print server things the size of a deck of cards that will let you put a printer anywhere and make it available on the network. As with all hardening processes, testing is important.

Vista also hardens systems a bit by keeping your systems from creating something called "LM hashes." Whenever you type a password into your computer, the computer doesn't store your password anywhere. Instead, it takes you password and subjects it to a mathematical function called a "hashing function" that reduces the password, no matter what length, to a 128-bit number. That's what gets stored on your computer and on your domain controllers, not your password; instead, the "password hash" is stored. Why do that? Because if someone gets your hash, then reversing the hash process and figuring out your password just by looking at the hash should be nearly impossible, if the system's designed right. Microsoft first started doing this back in the LAN Manager days of the late 1980s, and the hashes created and stored by LAN Manager are known as the "LM hashes." In designing the method of storing LM hashes, Microsoft built a fairly good hashing system given the power of computers at the time, but they made one serious error. By looking at the LM hash of someone's password, anyone can instantly determine whether the password that resulted in the hash was fewer than eight characters. Being able to instantly be certain that a particular password was seven characters or fewer is a powerful tool in the hands of bad guys.

With the advent of NT 3.1 in 1993, Microsoft used a different and more secure method of hashing. But Microsoft needed to worry about backward compatibility, and so whenever you changed your password, then NT created and stored two hashes: the LM hash and an "NT hash." Remember, if a bad guy gets your hashes, then he doesn't need to crack them both— cracking the LM hash will give him your password without any need of help from the NT hash. Storing LM hashes is potentially security nitroglycerine, but Windows XP and 2003 still create LM hashes by default. There's been a setting in Security Options, "Network security: Do not store LAN Manager hash value on next password change" in Windows for years, but Microsoft's disabled it by default because, again, older operating systems and network-attached devices may fail if they can't get LM hashes. That changes with Vista.

Personally, I shut LM hashes off my network in 2002 and haven't missed them, and I think that if you can tell your systems to stop creating LM hashes, then you should jump on it—but, again, I would strongly suggest doing some testing first. Vista, however, takes a stronger position and is the first version of Windows to shut off LM hashes right out of the box.

SearchWindowsSecurity.com also features excerpts from chapter eight, "Locking Up the Ports: Windows Firewall", of Mark Minasi's book, "Mastering Windows Server 2003 Upgrade Edition for SP1 and R2."

Mark Minasi is a best-selling author, commentator and all-around alpha geek. Mark is best known for his books in the Mastering Windows series. What separates him from others is that he knows how to explain technical things to normal humans, and make them laugh while doing it. Mark's firm, MR&D, is based in Pungo, a town in Virginia's Tidewater area that is distinguished by having one -- and only one -- traffic light.
Copyright 2005 TechTarget
This was first published in May 2007

Dig deeper on Microsoft Windows Vista operating system



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: