Okay, let me review and then I'll advance some more text that I've read
for
your analysis, provided you have the time and inclination to indulge
me.
By
the way, I will definetly look at the resources you've presented. You
can
take that to the bank.
Hashes:
1. There are only LM and NTLM hashes. I've seen text regarding LMv2 but
I
won't even go there for the purposes of this discussion.
2. The storing of LM hashes can be turned off by domain policy.
I suppose the storing of NTLM hashes cannot be turned off by domain
policy,
but more on that in a moment.
3. There is an NTLMv2 hash but it is not stored. It is generated by
using
the NTLM hash as a key, and used during the challenge/response phase of
authenticating to the network.
Authentication protocols:
1. There are four of them - LM, NTLM, NTLMv2 and Kerberos.
2. LM and NTLM protocols can be disabled via domain policy, forcing the
use
of NTLMv2 and Kerberos. Neither of these protocols transmit a hash
across
the
network.
Now for my final foray before going to read the resources you've
mentioned.
Here is text from a Microsoft article regarding hashes and protocols:
"Once the password goes to 15 characters, the LM and NTLM hash is not
stored
because it relies on a 14 character password."
The source for this sentence is:
http://www.windowsecurity.com/articles/Protect-Weak-Authentication-Protocols-Passwords.html
That sentence takes me back to my original post where I asked, "Does a
15
character
pass-phrase automatically get stored in an NTMLv2 hash? It certainly
won't fit into a LM or NTLM hash."
This is where I *assumed* there was a stored NTLMv2 hash because a
password
has to be stored somewhere, doesn't it? If it isn't stored in LM or
NTLM,
then where does it get stored?
And, finally, I'll ask, "Given that the above is true, and passwords
greater
than 14 characters are not stored in an LM or NTLM hash, why won't the
domain
security policy allow setting minimum password lengths greater than 14
charcters?"
<Lawson steps off of his soap box>
I've already seen your subsequent post regarding the possible hazards
of
disabling the NTLM protocol. Thank you for that. I'll be careful.
And now, I'm off to the TechNet website.
Thanks again,
Lawson...
:
The terminology is all confusing. Take a look at "value using the
16-byte
NTLM hash as the key. This results in a 16-byte value
- the NTLMv2 hash." What NTLMV2 [an authentication protocol] does is
to
use the NTLM [or known as NT hash or Unicode hash] hash stored in the
operating system as the key to use in the challenge/response for
authentication over the network to encrypt the nonce for the
challenge.
There is however no locally stored NTLMV2 hash of passwords. The link
below
explains a little bit more.
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&
"The NTLM, NTLMv2, and Kerberos all use the NT hash, also known as the
Unicode hash. The LM authentication protocol uses the LM hash"
I do believe in enforcing the use of very strong passwords as part of
and
the core step of defense in depth. Auditing and reviewing the security
logs
is a good way to get a feel of what is going on by looking for unusual
pattern of failed logons or use of administrators account when it
should
not
be used as in questionable times or from questionable computers. The
free
tool from Microsoft called Event Comb makes it easy to scan multiple
computer logs looking for specific event ID's and text strings such as
a
user or computer name. With Windows 2003 and XP Pro, particularly the
latest
service packs Microsoft gives the admin a lot of built in technologies
to
secure their network and data and the documentation to do such at
TechNet
Security homepage. While it may appear that larger networks may have
better
security that could be an illusion. Yes they may have a big budget for
hardware and software but they also have a lot more employees in their
support staff for IT and all it takes is one admin or support staff
that
is
not trained correctly, is lazy, and/or malicious to open a huge
security
hole as you are only as secure as your weakest link. This is sometimes
referred to as "layer 8" issues that include social engineering
attacks
which is too often overlooked as a serious vulnerability to address.
If you have not been there yet be sure to check out the TechNet
security
page and read the free guides such as the Windows 2003 Server Security
Guide, Windows XP Security Guide, Threats and Countermeasures,
Antivirus
in
Depth Guide, etc. The last link is to a great white paper on ipsec and
you
would want to read at least appendix A. Also if you are considering
ipsec
be
sure to test any ipsec policies first and beware that domain
controllers
MUST be exempt from trying to use ipsec for communicational between
domain
computers and domain controllers. --- Steve
http://www.microsoft.com/technet/security/default.mspx --- TechNet
Security homepage
http://www.microsoft.com/technet/security/topics/architectureanddesign/ipsec/ipsecch1.mspx
--- Server and Domain Isolation Using IPSec and Group Policy
"Lawson Poling, MCSA" <
[email protected]>
wrote
in
message Steve, thank you for your informative response. You've certainly
given
me
some things to think about, and to research. While doing more
research
I
came
across the following web page that contradicts your first sentence
which
states there is no such thing as an NTLMv2 hash. A portion of the
text
contained on the web page states:
"The Unicode uppercase username is concatenated with the Unicode
uppercase
authentication target (domain or server name). The HMAC-MD5 message
authentication code algorithm (described in RFC 2104) is applied to
this
value using the 16-byte NTLM hash as the key. This results in a
16-byte
value
- the NTLMv2 hash."
The URL for this info is:
http://curl.haxx.se/rfc/ntlm.html
I'm continuing to look in to your other recommendations, like using
IPSec
for network communications, encrypting data, etc.
Converstationally, we are fortunate to have pretty decent physical
security
in place i.e. Cisco firewall and router.
With regards to super-complex passwords, I'm trying to address the
fact
that
these systems are not bullet proof. This is evident by large
corporation's
networks that get compromised that have better physical security
than
we
do.
I'm considering outsourcing to Verisign the task of monitoring our
network
for unscrupulous activity. I hear they do this 24/7 and will notify
network
admins any time day or night if something pops up on their radar.
This
would
negate the need for 'super-complex' passwords since we would be able
to
respond to threats in a timely manner.
I'm going to test turning off NT and NTLM responses and utilize only
the
NTMLv2 and Kerberos authentication protocols.
I find this all very exciting stuff and again I thank you for your
input.
Lawson...
:
There is no such thing as an NTLMV2 hash. There are only LM and NT
hashes.
LM is very weak by today's standards. The reason it is turned on by
default
is for backward compatibility for W9X computers but it certainly is
easy
enough to disable via a security option. LM passwords can not be
longer
that
14 characters though both NTLM and NTLMV2 can be up to 128
characters.
While I am a believer of enforcing complex passwords the bigger
issue
is
if
you are concerned about someone trying to crack passwords on your
domain
computers you need to review the physical security of your
computers.
Domain
controllers [the grand prize] and any other sensitive computers
need
to
be
physically secured. Enforcing complex passwords of at least eight
characters
in length will make it extremely difficult for a user to try and
break
the
password of other users over the network. Sensitive user accounts
can
use
multi factor authentication of smart cards and the accounts can be
configured to required to use a smart card to logon.
If I can get access to a computer then I don't even care what the
password
is because I can access any data on it that is not encrypted via
proper
procedures. Passwords are an important part of network security but
don't
think that forcing users to use super complex passwords alone is
going
to
secure your network and data. Many users will gladly tell someone
else
their
password when that person talks a good game [social engineering]
and
too
many domain administrators will logon to domain computers [other
than
domain
controllers] with their domain administrator account which can
compromise
the most complex password. Data that absolutely needs to remain
confidential needs to be encrypted on the computer and network
[using
something like ipsec] and accessed and managed by well trained,
aware,
and
trustworthy employees. --- Steve
"Lawson Poling, MCSA" <
[email protected]>
wrote
in
message After reading some security articles about making passwords and
authentications more secure on a Windows Server 2003 domain, I
was
surprised
to learn that storing LM hashes is turned on by default, and that
it
is
broken up into two 7 character units. That would explain why,
when
using
L0ftcrack to audit user passwords with 8 characters, that the
last
character
was always found so easily. It places only one character in the
second
hash.
So much for the idealistic minimum 8 character passwords.
I also learned that the NTLM hash was a single 14 character hash,
but
it's
still as vulnerable at the LM hash. It would just take longer to
crack
a
solid 14 character password.
I thought I'd get clever and I made my password 15 characters
long.
L0ftCrack was no longer able to recognize it. It marked my user
account
under
the LM column as *empty* and won't even try to crack it. I got
all
warm
and
fuzzy and was feeling good about myself until I learned about
Rainbow
Crack.
My understanding about it is that it's hash tables only go to 14
