We are setting up a SharePoint 2010 site. Don't worry, this is not a Sharepoint question, just adding it for context. Most of the site will be anonymous, but some users are able to authenticate in and edit content. They use NTLM (users exist in AD). Is there any concern about exposing NTLM login for users that can modify content over the internet via http or should that only be exposed via https?

  • 1
    FYI, NTLM is deprecated. Microsoft recommends Kerberos instead (which is safe to use over plaintext protocols). – grawity May 5 '11 at 13:37
  • 1
    And to add to what @grawity said, any users behind certain proxies and filters (squid is one I know of for sure) won't be able to log in with NTLM authentication. – KJ-SRS May 5 '11 at 14:07
  • And before you ask, one can use Kerberos over HTTP, and SharePoint supports it. – grawity May 5 '11 at 14:13
  • More clarification, we are using NTLMv2 – Shane May 5 '11 at 14:33
  • 1
    @KJ-SRS: As long as a proxy supports HTTP/1.1 it won't present a problem using NTLM authentication. – Evan Anderson May 5 '11 at 14:43

You won't be exposing credentials in cleartext using NTLM over HTTP. You will be exposing everything else, so your data won't be secure from confidentiality or integrity breaches (eavesdropping or modification of the data "in flight").

  • That's okay, this is a public anonymous site. The only reason we need authentication is because it is a CMS, so certain users that have rights to edit content are able to log in via NTLMv2 – Shane May 5 '11 at 14:52

NTLM over plain HTTP is insecure. Attackers that passively sniff traffic or who perform a man-in-the-middle attack can use various methods to steal or abuse credentials. For example:

  • NTLM relay attacks: when a user thinks they are authenticated to SharePoint, the attacker can instead forward the NTLM challenge of some other service (like Outlook/Exchange or an SMB share) in the domain, and gain access to that as well. Even when the second service is using HTTPS!
  • Offline dictionary attacks: after observing an NTLM challenge and response, an attacker can recompute the exchange for some password P. When it matches, it means P was the user password. The attacker can keep trying P's until the password is found. The effectiveness of this attack depends on password strength, but by using standard tools, a good dictionary and stone GPU acceleration, even moderately complex passwords can be cracked.
  • Session hijacking: an attacker who is just interested in SharePoint can also simply ignore the NTLM exchange and take over the users' SharePoint session (e.g. by stealing cookies or injecting JavaScript). This gives them the same read/write access as the user.
  • Website spoofing: am attacker can show a fake login screen asking for AD credentials. Since users probably trust SharePoint, it's not unlikely they would fill them in and thus provide the attacker with a plaintext password.
  • NTLMv1 downgrade: depending on the client configuration, an attacker may be able to get them to perform an NTLMv1 handshake. This has all the cryptographic weaknesses of NTLMv2 (i.e. vulnerability to dictionary and relay attacks) but after cracking a two DES keys (pretty cheap and fast nowadays) it gives them access to the users' raw NT hash. A dictionary attack against this is far more efficient. Furthermore, this value can be used for a pass-the-hash attack, allowing the attacker to log in as the user (against most services) without a password.

Bottom line: treat NTLM authentication the same as authentication with plaintext credentials. In this case, this means you should use HTTPS of you want to protect against attackers on your network.


I don't know a thing about Sharepoint, but the generic approach to it would be to put a sniffer on it. If you can see the passwords or their hashes being passed, then it's bad. If you can't see it, then you need to look into it some more, it still might be lightly obfuscated (base64 encoding or something like that).

  • "if you see it, it's bad" doesn't always apply. NTLM v2 is a challenge/response protocol, supposed to remain secure even in this case (the password hash sent cannot be reused). On the other hand, authentication mechanisms very often have subtle flaws unnoticeable through simple visual grep of packets. (You cannot see the difference between a chunk of AES ciphertext and a chunk of XOR ciphertext.) – grawity May 5 '11 at 14:10
  • 2
    'If you see it it's bad' is true. 'If you don't see it then it's good' is not necessarily true however. With challenge/response protocols you gotta study the protocol of what is being asked and how the response is generated, then seeing if you can obtain all the necessary information. en.wikipedia.org/wiki/NTLM#NTLMv2 has the details of what gets used. Time can be closely estimated, user and domain names can be determined, so the only truly random bit is 8byte random nonce, so that can probably be guessed in not too many tries. – Marcin May 5 '11 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.