다음을 통해 공유

NTLM’s time has passed

  • 아티클

IMHO, Microsoft’s NTLM authentication protocol is getting a bit long on the tooth. Although we still support it for various reasons (many of which are obvious), you should look very sternly upon it if your application uses it.

In case you’re not familiar with the NTLM protocol, there’s a great write-up at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/microsoft_ntlm.asp.

There’s really very little reason not to migrate to the Negotiate SSP. If you haven’t considered migrating, you should do so sooner rather than later. The chief benefit of Negotiate is that it will use Kerberos if possible, and can securely downgrade to NTLM if it becomes necessary.

The benefits of Kerberos over NTLM are many—these are just a few:

  1. Huge performance improvement, mostly for server applications
  2. Kerberos is an open standard with a thriving community. NTLM is a proprietary protocol, and we’re looking for ways to deprecate it.
  3. NTLM is a four-letter word. Kerberos has twice as many letters.
  4. Kerberos in Vista will support the AES encryption type. NTLM won’t.
  5. Kerberos supports several modes of delegation. NTLM doesn’t support any.

But if these weren’t enough, there’s always the general security factor. Of the three flavors of NTLM (LM, NTLM, and NTLMv2), only v2 holds a candle to Kerberos in terms of security. Unfortunately, you can’t actually rely on people deploying NTLMv2 correctly, and even if you could, you still wouldn’t be as safe as you were if you were using Kerberos.

Let’s look a little closer at those last two assertions, shall we?

You can’t rely on NTLMv2 being deployed correctly

I’ve heard talk that NTLMv2 is cryptographically equivalent to Win2003 Kerberos (because both use RC4/HMAC). This is more or less true. However, if your application’s security depends on this strength of crypto being used, you are pinning lots of hope on a very sick donkey.

First off, in order to use RC4 with NTLM, you need NTLMv2. NTLMv2 will only be negotiated if your LmCompatibilityLevel is set correctly (see https://msdn.microsoft.com/library/default.asp?url=/library/en-us/gp/576.asp for what this means). This is an extra step that many system administrators may or may not actually do depending on what Operating Systems are present in the deployment.

As if this weren’t enough, setting this key to ensure NTLMv2 (since v1 and LM are Right Out) is negotiated effectively cuts off a machine (or a domain) from authentication using older versions of Windows. Obviously, MS does not support those, but let’s be honest: some deployments still use them.

So, a deployment that contains, say, Windows NT 3.51, would be unable to deploy NTLMv2. For this reason, you can’t count on system administrators requiring NTLMv2 and thus cannot rely on it to secure your application protocol.

Note that it’s safe to use Negotiate in these environments, even though NTLMv2 may not be available, because Negotiate can determine that Kerberos can’t be used to a target server and will drop down to whatever version of NTLM the deployment is configured for. This allows you to actually get Kerberos in situations where it is possible to use without forsaking NTLM for the situations where it is necessary.

Mutual Authentication

The biggest problem with NTLM, in my opinion, is that all flavors of it lack support for server auth. Some have claimed that NTLM has mutual auth because the server produces a challenge after contacting its DC over the netlogon secure channel so the “server” is really the DC you contacted, but this isn’t mutual auth. It would be server auth if you were sending messages to the DC, but you’re not—you’re sending them to a file server or a mail server, or whatnot.

So: all NTLM can actually guarantee a client application is that it’s talking to someone with a secure channel. Yeah, it’s better than nothing, but it may not be enough.

Consider a file server. If I want to hit a central install-point for my domain software (\\foo\bar\baz\InstallStuff.exe), then I want to authenticate to \\foo, and then ask it to start sending bits for InstallStuff.exe to me. In this scenario, I don’t know whether \\foo is really \\foo, or whether it might be some rogue server that happens to be joined to the same domain, or some other server somewhere in my domain that’s been penetrated.

Call to Action: Migrate to Negotiate!

If your application is currently using NTLM, you should migrate to Negotiate sooner, rather than later. Negotiate is smart enough today to know when Kerberos should be used, and when using NTLM is safe. Negotiate also gives applications a chance of using new authentication protocols when they come out.

I’ll write again on the specifics of how to migrate later, but hopefully this entry will get people started thinking about whether they really need NTLM, and keep developers from writing new code that uses it.

- David Christiansen

Comments

  • Anonymous
    January 01, 2003
    Hi, Steve again. I thought I would speak through a series of posts about what knowledge is critical to