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