Re: Password hashes

From: Lawson Poling, MCSA (LawsonPolingMCSA_at_discussions.microsoft.com)
Date: 10/30/05 

Date: Sun, 30 Oct 2005 14:28:03 -0800

Very good, sir. Thank you once again for indulging my queries, assumptions
and interpretations.

Class dismissed?

"Steven L Umbach" wrote:

> There are only two hashes used for storing passwords in the Microsoft
> operating system for user logon - LM and NT. It would appear that the
> article you are referring to is wrong in saying that password greater than
> 14 characters will disable storage of NT hashes of users passwords because
> that certainly is not true. NTLM uses the NT hashes of the users password
> and there is no dedicated NTLM hash for stored passwords . It will disable
> storage of LM hashes of user passwords used my LM authentication. The rest
> of Derek's article looks right on. You might try emailing him asking about
> that sentence. I respect Derek greatly but note that is not a Microsoft
> article. Here are three Microsoft articles that may be of interest by Jesper
> M. Johansson.
>
> http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint091004.mspx
> http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint100504.mspx
> http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx
>
> NTLMV2 does use the NT hash of the users password to encrypt the nonce for
> the challenge to the client just like NTLM but it uses a stronger hashing
> algorithm than NTLM and also does mutual authentication and offers some
> replay protection unlike LM and NTLM. Kerberos uses a similar method using
> tickets and has a default five minute window for replay protection. NT
> hashes of the users password are used for NTLM, NTLMV2, and kerberos
> authentication protocol. LM hashes of the users password is only used by the
> LM authentication protocol. Offhand I have no idea why you can not enforce
> passwords longer than 14 characters. --- Steve
>
>
>
> "Lawson Poling, MCSA" <LawsonPolingMCSA@discussions.microsoft.com> wrote in
> message news:CB775A67-EE60-4345-8E04-46AF16568323@microsoft.com...
> > 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...
> >
> > "Steven L Umbach" wrote:
> >
> >> 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" <LawsonPolingMCSA@discussions.microsoft.com> wrote
> >> in
> >> message news:15C2FF59-2C55-430A-85D8-4A091DF80793@microsoft.com...
> >> > 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...
> >> >
> >> > "Steven L Umbach" wrote:
> >> >
> >> >> 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" <LawsonPolingMCSA@discussions.microsoft.com>
> >> >> wrote
> >> >> in
> >> >> message news:DD53C017-8BD0-4EDD-B5B6-7CD8C51C9611@microsoft.com...
> >> >> > 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

Relevant Pages

  • Re: Password hashes
    ... >> There are only two hashes used for storing passwords in the Microsoft ... NTLM uses the NT hashes of the users password ... >> and there is no dedicated NTLM hash for stored passwords. ... >> LM authentication protocol. ...
    (microsoft.public.windowsxp.security_admin)
  • RE: ADS Password Storage Protection
    ... In Windows it is LM or NT (sometimes called NTLM) hashes. ... NTLMv2 refers to the authenication protocol that exchanges the hash ... between the client and server authentication database. ...
    (Security-Basics)
  • Re: Forms and integrated authentication combined
    ... Because when Integrated NT Authentication is used, ... place between IIS and IE. ... Remember that it is very difficult to get a users password out of Windows ... 2000 Server because the password file is heavily encrypted. ...
    (microsoft.public.dotnet.framework.aspnet)