3

I have a web application that I'd like to authenticate to using pass-through NTLM for SSO. There is a problem, however, in that NTLMv2 apparently will not work in this scenario (without the application storing an identical password hash).

I enabled NTLMv1 on one client machine (Vista) using its local group policy: Computer->Windows Settings->Security Settings->Network Security: LAN Manager authentication level. I changed it to Send LM & NTLM - use NTLMv2 session security if negotiated.

This worked, and I'm able to login to the web application using NTLM. Now this application would be used by all of my client machines... so I'm wondering what the security risks are if I was push this policy out to all of them (not to the domain controller itself though)?

Improve this question

5 Answers 5

Reset to default
5

It's a really bad practice, kinda like enabling WEP to protect your WiFi because you have a Windows 98 computer that won't work with WPA2. It's 2009, Kerberos works if you really, really need SSO.

I also consider integrated authentication for websites to be a bad practice in general as it often leads to oddball issues when users have multiple accounts (we use separate user/admin accounts), requires you to muck around with IE trust zones, and requires you to use IE or fiddle with Firefox settings.

Given the trainwreck that IE has been and continues to be since 2002 or whenever IE6 came out, (ie. The out of band ActiveX patch) do you really want to commit to the platform?

Improve this answer
3
  • This isn't a Microsoft product, and it's not even running on a Microsoft server. What I don't like is the idea of users typing usernames and passwords into a web application. Guess which password they're going to use? So you've got domain passwords stored in browser caches all over the network. This particular application can supposedly do Kerberos, but I've had difficulty with it in the past. I dunno.
    – Boden
    Jul 30, 2009 at 15:34
  • Internet Explorer will cache credentials as well. Look at the "Documents and Settings\Application Data\Microsoft\Credentials\<SID>\Credentials" directory. You're better off just having users authenticate on the website, so at least TLS will protect the passwords in flight. Hardening saved passwords in the browser isn't a trivial thing to do, but it's better than relying on a flawed protocol.
    – duffbeer703
    Jul 30, 2009 at 16:14
  • Clarification: I should have said "IE will cache NTLM credentials as well"
    – duffbeer703
    Jul 30, 2009 at 16:15
5

NTLM was replaced by NTLMv2 in NT4.0 SP4. That's over a decade ago. NTLM is harder than LM to crack for passwords, and NTLMv2 is much harder. There is a reason Vista defaults to NTLMv2 only. Rainbow tables have been compiled for the complete LM password space, and last I heard work was well in progress to do the same for the NTLM space. NTLMv2 hasn't been done yet.

Yes, there are increased security risks by doing this. Whether or not they matter to you is up for your own risk assessment.

Improve this answer
2

As Adam and sysadmin stated, this is a very bad idea from a security perspective (not to mention from a legacy perspective as it was replaced in the NT 4 days and NTLMv1 could potentially be removed from future versions of Windows). What about using Kerberos for authentication/SSO? It is more secure than even NTLM v2, works in double-hop scenarios, and will be supported (both inside and outside of Microsoft) for the forseeable future.

Improve this answer
1

If you have anything sensitive, I wouldn't do this.

If a hacker sniffed your NTLMv1 SMB traffic, they could use something like Cain & Abel with Rainbow Tables (HalfLMChall might be fastest) or RainbowCrack to crack the password. If the password is seven characters or less, this could be done in a day.

NTLMv2 creates the hash using other realtime variables, and also uses 128-bit password space with MD5 (not 64 bit DES encryption), so it takes MUCH longer to crack (more on cracking NTLMv2 here).

NTLMv1 also stores passwords locally in hashes that can be used to authenticate without needing to know the original password. So if someone can own a local machine as a local admin, they can extract hashes of a domain admin or domain user and get the information they can get off the server without even knowing their password (more on this here).

If you really wanted to go the NTLMv1 route, then I would make sure all passwords are more than 14 characters, and include special characters.

Improve this answer
1

Yep, one problem with NTLMv1 is that it uses DES, which nowadays is considered weak being only 56-bit. DES cracking is still hard at this point, though. However there is another weakness. In NTLMv1, the LM/NT hashes are turned into three different DES keys and then they are used to encrypt a challenge. Since the hashes are 128-bit and DES is only 56-bit, the third key is only 16-bit, with the rest filled with zeros, making it easy to crack, revealing two bytes of both NT and LM hashes. NTLMv2 fixed this by using HMAC-MD5 instead. MS-CHAPv1 had the same flaw too, and despite the fact that it came at the same time as NTLMv2, MS-CHAPv2 did not fix this. I wonder why.

Edit: Now CloudCracker has a cloud DES brute-forcing service that takes advantage of this problem in MS-CHAPv2.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .