back to article NTLM authentication: still broken after all these years

A 15-year-old vulnerability in technology used to authenticate users on Windows and Unix networks continues to put the organizations that rely on it at risk, a security researcher said on Thursday. Short for NT LAN Manager, NTLM and its offspring, NTLMv2, is a challenge-and-response protocol for logging onto Microsoft accounts …


This topic is closed for new posts.
  1. Henry Wertz 1 Gold badge

    NTLM is broken by design

    I don't think there is a "comprehensive patch" possible for NTLM. It is simply not a robust authentication. Why? The "LM" itself says it -- it's from the days of Lan Manager (early or mid 1980s), NetBIOS, and so on along with the SMB (Server Message Block) file sharing and all that good stuff. It was designed to have low enough memory usage and CPU usage to run reasonably on the 4.77mhz, 8mhz, 16mhz machines of the time, and furthermore LanManager stuff assumed a closed network -- NetBIOS was not routeable. Why did Microsoft adopt it in Windows (either NTLM *or* SMB, or the NetBIOS-based name services?) I really don't know, but they did.

    Anyway, there is a "simple" solution -- Kerberos. (For Windows use this is Active Directory). I'm no Microsoft fan, but they recognized NTLM's weaknesses like 15 years ago; Kerberos was designed recognizing that a lot of the login systems of the time were quite weak, it specifically does avoid capturing and reusing authentication tokens for instance. So why does NTLM still exist? Well note the quotes on "simple" -- setting up Kerberos is just not that simple, and if an environment is closed off, it may well be overkill.

    1. Chris Miller

      Very true

      I entirely agree, Henry - though my inner pedant can't help pointing out that it's actually late '80s tech (OS/2 appeared in 1987, NT Server in 1993).

      The problem is that (in many cases) simply turning off NTLM may break legacy apps. It's basically the same issue that has people trapped using IE6 - they may well know that there's a massive security issue, but can't get the (very much non-trivial) costs past the bean-counters.

    2. TeeCee Gold badge

      "Why did Microsoft adopt it in Windows....."

      Er, back-compatibility? Windows had to get its toe in the door of LAN Manager / OS/2 shops and needed to play nice to do so.

      Exactly the same reason that the big-boys' UNIX versions (HP-UX, AIX etc.) have maintained and working functionality that was officially deprecated a decade or more ago. When you're targetting the corporate market, you have to cater for glacial change speeds and Rule 1 is: "Don't b0rk anything that works now, unless you're 100% sure that nobody's using it".

    3. Peter Kay

      Appropriate for the time

      A small nitpick : NetBIOS is the controlling protocol, NetBEUI is one of the underlying network transports, NetBIOS name servers/WINS being required when running NetBIOS over TCP/IP. I never tried it over SPX.

      Anyway, for the time the technology was appropriate. IP in the mid to late eighties was not always bundled in operating systems, was of variable quality, more difficult to set up and harder to maintain. Lan Manager/Server were used by some SMEs, many more used Netware.

      At that time script kiddies were not so prevalent, comparatively few people were connected to the Internet, and like many Internet protocols (i.e. FTP), the system was not designed to protect itself from deliberate concerted attacks.

      From there the future is easy to understand. Any significant new product (NT, OS/2 32 bit) had to retain compatibility with existing products to gain market share. They have made changes over time but people are resistant to change.

      A more significant question is what the sensible alternative is. NFS has had its own issues and was vastly less reliable than SMB for a long while (timing issues with file movement were a particular problem).

  2. Anonymous Coward
    Anonymous Coward

    The title is required, and must contain letters and/or digits.

    Man-in-the-middle require fooling the user to send their data to them instead of where they intended - so the moral is don't trust unsecured networks.

    Replay attacks require recording the packets from a client on a broadcast network (or on one of the routing devices between them and the endpoint) - so the same moral applies here.

    Most common solution where Kerberos isn't possible is to use HTTPS & Form-Based Authentication.

    Alternatively, a traditional or SSL VPN when accessing a corporate network from an untrusted one has been the recommendation for years now.

    1. Geoff Campbell Silver badge

      Define "unsecure"?

      Trouble is, a MITM attack can be as simple as catching and responding to an ARP packet before the real recipient, everything else can follow on from there. So any network is insecure at this level, as ARP packets are broadcast to all nodes within the broadcast domain, which in some corporates can cover several hundred PCs, or even more in poorly implemented networks.

      Anyone doing *any* corporate work over unknown public wireless networks needs their bumps feeling, for this and about 1,839 other reasons.


    2. BristolBachelor Gold badge

      Insecure networks

      I can see the CAT5 cable come out of the back of my PC, and plug into a socket on the floor. I cannot see where the cable goes, and even less can I see the packets that flow along the cable and see where they end up.

      Ergo I am on an unsecure network.

      If I now say that I can't trust it, and cannot enter my username/passwords to login, I can do no work...

  3. Steen Larsen

    Where's the news?

    WOW! An old authentication protocol which has been abondoned by its creator and replaced by Kerberos is broken. Yes, we all knew that, thanks.

    Suggestions for similar interesting articles:

    SSLv2: still broken after all these years.

    HTTP basic authentication: still broken after all these years.

    SSHv1: still broken after all these years.

    Telnet: still broken after all these years.

    Wow, this is getting exciting! ;-)

    May I suggest to read some excellent The Register articles about how media should do some background checks before passing on news from other sources.


    To the Anonymous Coward who wrote:

    "Man-in-the-middle require fooling the user to send their data to them instead of where they intended - so the moral is don't trust unsecured networks."

    The purpose of most security protocols is to allow trusted transactions on non-trusted networks. The benefit is that you do not have to trust the network. That is good, for a network is a big and complex beast that should never be trusted IMHO.

    1. Steven Knox

      If only it were so.

      Sadly, NTLM has NOT been fully abandoned by Microsoft.

      While deprecated, it is still available in Windows 7 and 2008. More to the point, it is enabled by default and will be used as a fallback to Kerberos authentication (which, in my experience, happens way too often) in the millions of Server 2003, Windows XP, and Windows 2000 boxes still out there.

      So, as long as those machines are out there with NTLM in use or potentially in use, this will continue to be news.

    2. Anonymous Coward
      Anonymous Coward


      "The purpose of most security protocols is to allow trusted transactions on non-trusted networks. The benefit is that you do not have to trust the network."

      I would agree with this, however AFAIK NTLM is an authentication protocol not a security protocol.

      The general consensus seems to be that this is another non-story, though.

  4. Birdman55

    Ray should not then try to put PhoneFactor forward as a solution

    Mobile phones as an authentication platform have been utterly discredited from so many angles its not funny. We have blackhat demos breezing past mobile based security not just from a trojan perspective but with fundamental gsm protocol based attacks. Not to mention the obvious that its generally quite easy to ring up a phone company and request all calls to be forwarded with no work at all. The PhoneFactor website compare section correctly asserts that other authentication methods are vulnerable to MITM attacks etc but then qualifys its own methods as secure by using the word "generally" not vulnerable.. this is misleading, Phone based authentication IS just as vulnerable to MITM attacks in fact more so because there are so many more angles of attack with a mobile.

    It is good to point out vulnerabilities but people in glass houses...

This topic is closed for new posts.