Microsoft shows venerable and vulnerable NTLM security protocol the door Microsoft has finally decided to add the venerable NTLM authentication protocol to the Deprecated Features list. The announcement means that admins dragging their feet to move to something more secure must start making plans. Active feature development for all versions of NTLM (NT Lan Manager) has now ceased, although the …
While I would like to agree, the reality is that many services and applications don't and won't support Kerberos only authentication. They were coded to use NTLM, and windows always supported it, so it was the lowest common denominator. Fortunately any project using a proper library may either see it transparently shift or at least be able to recompile things. Others can probably glue stuff back together with a SAMBA server as a Swiss army knife.
Many app developers that have to re-code may jump past local Kerberos authentication and implement SSO/Passkeys/Oauth/SAML etc etc etc instead.
Kerberos was cool tech, but like CORBA it's unnecessarily complex, and it never got updated to handle stateful or port level connections, so it can't safely handle NAT or IP sharing. Kind of a problem when any kid's mobile device may also be a hot spot.
Still, NTLM was long past where it should have been scrapped. I found a MITM attack where you could grab credentials off the local machine and recycle them in a web connection to impersonate the client. Didn't get fixed for more than 15 years, almost 20 actually. NTLM and Netbios are two things I will rest easier knowing are gone completely from the windows code base.
Sadly, open source will probably support it for decades for (mostly legitimate) compatibility reasons. Any bets on which UNIX service gets a zero-day after M$ ends NTLM support? I'm going with SystemD even though Samba is the safer bet.
There's no weakness in Challenge-Response protocols themselves. It's just that NTLM originally used SHA-1 and 64-bit DES, which is outdated and weak. Newer versions used MD5, which too has been shown to be insecure.
They could've upgraded to SHA-256 and AES-256 with limited or no fallback options, which would've made it secure once and for all, but didn't.
Of course they did not. Not because of "newer hash is better", it is because storing the hash is insecure by design. If you invest a bit work you can steal the hashed login credential from one machine, transfer it to another, and then (re-)play around with it. Even though the newer MD5 NTLMv2 is not just MD5, it is MD5+hmac+salt. Else it would have been cracked long ago.
The kerberos way works a bit like a mini-readonly-DC, and then you have not that type of cached credentials by design. It is always a full auth. Yeah, cloning the VM and start a clone would work, once, 'cause then the original or the clone is flagged as "wait, why is it so off? Rejected!" by the Active Directrory. If you ever had a AD-split-brain scenario you know what I talk about. Except here it is more simple, the AD can kick them, i.e. flag that machine account as "contaminated", and all user accounts which were on that machine as well. The latter in theory only, that is a question for the AD gods at Microsoft.
Since the protocol fundamentally exists for compatibility with legacy Open Source systems, upgrading it to an incompatible protocol would be the same as removing it.
Microsoft has no desire to support legacy Windows systems. but they were stung by the outrage in Open Source users when they turned off default NTLM V1
and SMB1... Though SMB1 is the lesser problem.
NTLMv1 is the problem. Not because of Windows, because of, for example, Cisco and Fortigate, including the newest software from those on new devices (or their software on a server).
Here a nice example what those two are trying - faking SMB2 with NT LM 0.12 (Jep, not even v1). Which Server 2022 rejects no matter what you do, and Server 2012 R2 too if configured secure. It is surprising seeing such things in a packet capture. In 2024. And I am SO thankful for that Microsoft post, 'cause the vendors cannot "talk around" the issue.
Yeah, this mess has a long shadow. Too many 3rd parties are using a hacked together implementations to produce 3rd party compatible authentication. This is also going to hit a ton of services, as LDAP and a slew of other things had NTLM shoe horned into them. Like internet exploder. Tons of vintage apps are going to poop themselves in strange and interesting ways.
Cisco is still using 90's era Java code to link to AD, I doubt Fort is much different. Microsoft didn't help by refusing to release good libraries or open up the licensing for decades.
Also some may not be able to log into systems restored from backups, VMs or old hardware that was offline for too long. So it could Eff up some peoples day if that old stuff is needed for compliance or continuity of business. Not insoluble if you though of it before you needed it, but a ton of wasted time and money if you had to "fix" that situation for more than a couple of images.
Kerberos V was launched in 1993 apparently the same year as NTLM. Kerberos 4 dates from the '80s and Needham-Schroeder the late '70s.
So both NTLM and Kerberos V are now in their third decade. Perhaps time for something newer? (Although not designed by the MS cryptomavens. Please!)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
