Meeting the InCommon Assurance profile criteria using Active Directory

["Coleman, Erik C" <>]

I always get confused between the hashes and the protocols too!  From what I understand over the years (and to hopefully add clarity):

 

·         MSCHAPv2 requires the NTLM(v1) authentication protocol enabled on a DC.  The much-desired “level 5” LAN Manager Authentication Level (allowing only NTLMv2 with session security and refusing anything else) would break MS-CHAPv2.

·         There is only one NTLM hash stored on disk—both NTLM(v1) and NTLMv2 authentication protocols rely on this stored NTLM hash.

·         The CERT guidelines do not point out clearly that disabling of LM hashes does not actually remove existing LM hashes—a password change for each user is required after deploying those settings.

 

-Erik

 

 

--

Erik Coleman <>

Manager, Enterprise Windows Operations

Campus Information Technologies and Educational Services (CITES)

University of Illinois at Urbana-Champaign

 

 

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Wednesday, May 15, 2013 8:28 PM
To:
Subject: [AD-Assurance] RE: US-CERT as an authority on security - for alternative means - on NTLMv2

 

Actually, I should perhaps rescind some of the comments here.

 

I equated the NTLM password hash (bad security on pw storage) with the MSCHAP challenge protocol (bad security on the wire). It’s the latter which was broken in the link I sent. The NTLM challenge protocols are different things than the NTLM password hash. So I think I conflated things.

 

End result (if I’m not still confused!):

 

·         MSCHAP challenge protocol = bad security on the wire

o   eduroam: Does MSCHAP inside a TLS tunnel, so maybe not so bad on the wire

·         NTLMv2 challenge protocol

o   Better than LM, NTLMv1, NTLMv1 with session security, all of which are basically broken on the wire (and are all roughly equivalent to MSCHAP)

o   Possibly still unbroken on the wire, I’m honestly unclear at this point!

o   Requiring NTLMv2 (and not LM or NTLMv1) is already in the AD cookbook; i.e., we could go with Jeff’s original suggestion

·         NTLM hashes of passwords = bad security on passwords at rest

o   NTLM password hashes are used in support of MS-CHAP challenges and, I believe, NTLMv2 challenges.

o   Enabling NTLMv2 (and certainly MS-CHAP) may not invalidate “on the wire security”, but does appear to affect “passwords at rest” security.

o   Does BitLocker address this this case? We may have said that it does.

 

Sorry for adding confusion with my previous post.

 

--- Eric

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, May 15, 2013 4:34 PM
To:
Subject: [AD-Assurance] RE: US-CERT as an authority on security - for alternative means - on NTLMv2

 

I still am concerned that storing the NTLMv2 hash is itself a problem, as it is unsalted MD4 (as I understand it) and not really strong enough. The NTLM challenge protocol over the wire any other protection is pretty broken; see https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ to get some warm fuzzies.

 

Cloudcracker came out in 2012, so was since the document you note below.

 

 

Side note related to eduroam in particular:

 

I had a back and forth with our networking folks about NTLMv2 use for eduroam. I was unaware that when used in eduroam, the NTLM challenge actually occurs within an encrypted channel (TLS tunnel). Given that, even though NTLMv2 itself is problematic its specific use in eduroam is not particularly vulnerable to eavesdropping on the wire. (I’m also ignoring that several PPTP clients store the plaintext password locally for purposes of generating the NTLM challenge, as that’s more a client than a server issue).

 

--- Eric

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, May 15, 2013 2:37 PM
To:
Subject: [AD-Assurance] US-CERT as an authority on security - for alternative means - on NTLMv2

 

Here’s a fairly recent (2011) document from the US CERT Cyber Alert System which says (in addition to following NIST SP800-53) that administrators should…

 

Consider adding the following measures to your password and account protection plan.

·         Use a two factor authentication method for accessing privileged root level accounts.

·         Use minimum password length of 15 characters for administrator accounts.

·         Require the use of alphanumeric passwords and symbols.

·         Enable password history limits to prevent the reuse of previous passwords.

·         Prevent the use of personal information as password such as phone numbers and dates of birth.

·         Deploy NTLMv2 as the minimum authentication method and disable the use of LAN Managed passwords.

·         Use minimum password length of 8 characters for standard users.

·         Disable local machine credential caching if not required through the use of Group Policy Object (GPO). For more information on this topic see Microsoft Support articles 306992 and 555631.

·         Deploy a secure password storage policy that provides password encryption.

 

http://www.us-cert.gov/ncas/alerts/TA11-200A

 

OK, so when CERT says “LAN Managed passwords” we’re savvy enough to know that means LM HASH.

 

CERT recommends using NTLMv2 and disabling LM hash. Both agree with the AD Cookbook.

 

The password composition, history, length, and dictionary-type checks speak to the entropy requirement in both Bronze and Silver profiles.

 

I think we have already determined that even for Bronze level passwords, the minimum entropy should be sufficient for Kerberos protocol to meet the Resist Replay, Resist Eavesdropper, Resist Hijack, weak MitM, etc.

 

US CERT has many more recommendations for general security, but the above may be reasonable as an authoritative reference to say that US CERT recommends NTLMv2 as a minimum, which should help in an alternative means proposal when developing the specific text to use for the assertion, or for the documentation for why and how regarding comparable or superior.

 

I can see that it may be challenging to claim that NTLMv2 is comparable or superior to Kerberos, and probably even tougher compared with Kerberos keys in the AES ciphers.  The RC4-HMAC issue comes up here too, as well as MD5.  Comparable in terms of being encrypted, yes.  Can a claim be made for strong enough encryption at 8 characters?  9?  12?  15?  It is clear that the algorithm is not approved.  Are there any comparable terms such as comparably strong cryptographic hashing?

 

Again, this is just one authority to reference when developing an alternative means proposal.  But it is one that actually says “Deploy NTLMv2 as the minimum.”

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu