Microsoft will finally kill obsolete cipher that has wreaked decades of havoc
arstechnica.com128 points by signa11 4 months ago
128 points by signa11 4 months ago
There are so many problems with this article and the previous one it references (How weak passwords and other failings led to catastrophic breach of Ascension).
Specifically, RC4 is a stream cipher. Yet, much of the discussion is around the weakness of NTLM, and NTLM password hashes which use MD4, a hash algorithm. The discussion around offline cracking of NTLM hashes being very fast is correct.
More importantly though, the weakness of NTLM comes from a design of the protocol, not a weakness with MD4. Yes MD4 is weak, but the flaws in NTLM don't stem specifically from MD4.
Dan Goodin's reporting is usually of high quality but he didn't understand the cryptography or the protocols here, and clearly the people he spoke to didn't help him to understand.
EDIT: let me be more clear here. MS is removing RC4 from Kerberos, which is a good thing. But the article seems to confuse various NTLM authentication weaknesses and past hacks with RC4 in Kerberos.
Obviously RC4 itself isn't the problem. The problem is that Microsoft ships a "ciphersuite" that includes a bad password-based key derivation algorithm that also happens to be tied to a whole pile of bad cryptography. And the real, real problem is that Microsoft still ships a design in which low-entropy passwords can be misconfigured for use in encrypting credentials, which is a nightmare out of the 1990s and should have been completely disallowed in 2010.
But I'm not going to get particularly picky if people identify the bad ciphersuite by the shorthand "RC4", because even Microsoft does this: https://www.microsoft.com/en-us/windows-server/blog/2025/12/...
> But I'm not going to get particularly picky if people identify the bad ciphersuite by the shorthand "RC4", because even Microsoft does this
Microsoft is actually talking about RC4 there, the article is conflating NTLM and RC4 things together.
What are the bets that the NSA has been encouraging Microsoft to keep shipping this?
Low.
While the NSA would, absolutely, use it to elevate existing internal access - it is such low-hanging fruit that they have enough alternative tools in their arsenal that it isn't a particularly big loss. Most of their competent adversaries disabled it years ago (as has been best-practice since 2010~).
More likely, it is Microsoft's obsession with backwards compatibility. Which while a great philosophy in general has given them a black eye several times before vis-a-vis security posture.
Most importantly, the NSA is not just about spying, it is also about protection.
A weakness anyone can exploit in software Americans use is not a good thing for the NSA. If they were to introduce weaknesses, they want to make sure only they can exploit them. For instance in the famous dual_ec_drbg case where the NSA is suspected to have introduced a backdoor, the exploit depends on a secret key. This is not the case here.
On the other hand if Snowden has shown us anything, it is that the NSA is more stupid than it looks.
There are tons of old printers/copy machines that allow SMB access or AD auth that will never see a software update that will break.
Honestly I blame the copy machine manufactures for requiring service contracts for security updates on a lot of this.
Those stupid MFD machines have been the bane of my existence as a sysadmin ever since I started in this career many, many years ago.
It's these machines, plus a few really old windows-only apps deep in basement of enterprises that keep this old tech around. There's usually no budget to remedy, and no appetite to either from leadership
Its also what happens when the people buying the tech are disconnected from the ones implementing. Microsoft caters to this.
Just photocopy some currency. Depending on the machine, it has a good chance of bricking the machine with an obscure error code until a service tech comes out, at which point you can point out this machine is really old and why don't we get a new one.
If you'd rather not commit attempted forgery, just print out some Wikipedia pages about the EURion constellation, which is what they detect in money.
Joking, obviously.
Microsoft supporting something doesn't mean that you have to use it. There's something as personal responsibility.
Do manufacturers also have personal responsibility for making safe products, or does it fall to consumers to become experts in the myriad different fields necessary to asses the safety of every product they buy?
Which, in this case, is higher quality as the article has a bunch of mistakes and misinformation in it.
Given the time it's been since deprecated, I'm assuming most older versions of Windows since 2000 and Samba have long since supported more secure options... though from some comments even the more secure options are relatively weak by today's standards as well.
Aside: still hate working in orgs where you have a password reset multiple times a year... I tend to use some relatively long passphrases, if not the strongest possible... (ex: "ThisHasMyNewPassphrase%#23") I just need to be able to remember it through the first weekend each time I change without forgetting the phrase I used.
Depending on your organization, it can sometimes help to point the right compliance person to the latest NIST guidelines, specifically:
https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
> Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
One of the nice cases where it can be helpful that standards themselves, which you can point to, have said to stop doing that.
Yeah, I've gotten headway in this in other places I've worked... heavy advocate for the only requirement being a minimum length with the recommendation to use a "phrase" as well as not requiring rotation in terms of less than a year at a time if at all... though not strictly matching NIST, some ops find a never require change hard to swallow.
I wrote an authentication platform used by a few govt agencies. The irony is all my defaults match NIST guidelines (including haveibeenpwned lookup on password set/change), but needed to support the typical overrides for other hard requirements that tend to come from such agencies in practice.
>> Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
> though not strictly matching NIST, some ops find a never require change hard to swallow.
I think they're right about that. A scheduled change just represents the accumulating probability that there's been a compromise somewhere that didn't come to your attention.
It seems like it would make more sense for a scheduled change to affect all passwords at once, though.
There has to be some balance though, as requiring change too frequently encourages the use of insecure but easy to remember passwords, or password that are very similar to the previous one thus failing the purpose of the change (e.g. a password containing the year, and the employee only changes the year every time). Best would be pushing for the use of a password manager or auth tokens like Yubikeys.
On changes, as I've mentioned in other threads, I don't think once a year is too bad... also, I'm an advocate of SSO as much as possible with a strong MFA (ideally push selection) option for work orgs. It reduces friction and can actually improve overall security if appropriately managed... that said, building internal apps that have appropriate application access is often harder still in these environments.
I got to work one morning recently, got a message that our MDM required me to change my password, logged into the MDM, turned off that obsolete option, and announced to the company via Slack that we're not doing that anymore.
Every now and again I ponder if I'm happy where I'm at careerwise, and then something like this reminds me that I have the authority to make these decisions, and I decide that yeah, I like being me.
Unfortunately, not all guidelines have caught up. PCI-DSS still requires password changes every 90 days for anything in scope (the cardholder data environment, anything that might even remotely touch payment card data).
Not with MFA. Not for a while now. And regardless, the word(s) you are looking for is "compensating control".
> point the right compliance person to the latest NIST guidelines
This only works if that's the only standard they're adhering to. At my employer, the password changes are mandated by their "cyber insurance" policy which hasn't caught up with the times.
I had to help a friend with a small business through a "cyber insurance" policy compliance questionnaire once and it was an incredible exercise in frustration. I would have felt certain the policy was a scam if it wasn't being mandated by a real insurance company the small business did other policies through. The questions didn't seem to have been written by someone with technical experience. Many of the questions wanted Yes/No binary answers for things that are complex technically. Some of the questions led to good discussions about security improvements for a small business, but most of them seemed "cargo culted" from large enterprises without real application to a small business.
That did not leave me a strong impression of "cyber insurance policies". I suppose it also did leave me wondering how much we've left very small businesses behind in security as a culture.
Fine until you run into the filter that prevents the new password from having any of the same substrings longer than some limit compared to the old one.
IMHO there are two requirements for a good password:
1. It must be hard for a computer to guess.
2. It must be easy for a human to remember. If you can not set a secure password and then remember it a week later it is a bad password.
This is why I really hate overly strict password requirements that make it hard to remember. These cause people to write it down or do things that appease the password checker but don't make it harder to guess.
3. Saved in a password manager
That replaces number two and is the correct alternative in most cases.
There are cases where a password manager may not solve the problem, though. It doesn't help if I forget my disk encryption or work AD password and I need to be able to login before I can get to the password manager in the first place. Enterprise IT is also where you find some of those frustrating password policies, such as long and complex passwords with mandated changes every month or two, and where you usually can't choose your management tools.
Of course those particular passwords usually get typed so often that remembering them isn't much of a problem. And password managers work well for pretty much all secrets that aren't needed that often.
Yeah. I've been in the habit of keeping the (encrypted) password file in multiple places. So I can even get the password off my phone if I really need to.
Although: be careful of cloud solutions
Until you need to login some place and don't have access to your password manager.
I mean this is what I use 1password for.
If it's the IT managed computer login then you couldn't use a password manager for it, right?
I think this is more the realm of using windows hello or apple touchid (AFAIK no good, simple, standard built-in way exists for linux distros) to get the first OS login and then you can use your password manager when you are logged into the OS.
Hardware MFA is available for logins, including Linux.
What method/program are you talking about? Does it support FDE? Is it reasonably supported with the methods expected by end users (fingerprint, face, smartcard, etc.)?
Everytime I've tried its been finicky and had to use non-standard tools to get it working.
I'm a different commenter but yeah, solutions exist. For example systemd-cryptenroll let's you use a FIDO token (or TPM or PKCS#11 smartcard) to unlock your encrypted disk and it's very easy to set up. Quite literally a single command.
Windows Hello serves the same purpose for Windows, though I'm sure there are caveats/differences.
If it's a fido hardware token you still need to make sure you have a backup token. It's a lot simpler on windows/macos where you can use biometrics for the same purpose.
You can setup multiple keys. It would be crazy not to include a simple ascii hash key in addition.
I tend to never use my password manager for my primary OS logins for desktops/laptops I physically access. Fortunately, I rarely have to keep more than 5 or so memorized at a time (including my password manager, Bitwarden/Vaultwarden).
Reasonable! Anyone who cares about AD security has been AES-only for at least a year now, and most likely much longer, and it's not like these mitigations are especially hard, unless you're still running some seriously obsolete software.
Nope. AES is not trivial to implement securely, so most implementations simply rely on hardware support. ChaCha20 and XChaCha20 are more secure ciphers.
Anyone who cares about AD security has left AD for a long time, no ?
AD is perfectly fine. It's actually really good at what it is: a highly-available Kerberos implementation with an integrated directory server. It's not as dominant as it used to be because there are better ways to handle identity for web applications and zero-trust environments, but I don't think that diminishes what AD was good at.
AD has built-in mecanisms where a random person can execute code on the AD themselves
You just have to not make a mistake (easy, just be perfect!)
Most people are not perfect; Hence, most people have security issue with AD (see the never ending tail of cryptolocked companies)
> AD has built-in mecanisms where a random person can execute code on the AD themselves
Could you provide an example? I'm sure I know what you're talking about, but the way you put it I'm having a hard time figuring out what you mean.
> Most people are not perfect; Hence, most people have security issue with AD (see the never ending tail of cryptolocked companies)
Yeah, but, how many of those ransomware attacks exploit misconfigured AD environments rather than something more banal like harvesting credentials accidentally checked into Git, or spear phishing for a target? Identity, in general, is hard.
AD allows connections between two computers that are registered against the active directory, including a random laptop and the AD themselves
This is a fundamental difference versus something like oauth: in the former, everything is done to allow RCE on the AD: the code exist; in the later, everything is done to prevent RCE on the issuer;
Identity is hard ? Identity is a lot simpler once you assume that:
- people make mistakes
- code is buggy
- infrastructure has issue
"allows connections" isn't code execution. An actual example would be really helpful here.
In the windows world, you connect to a server using RDP. I thought this would be implied. RDP is a mean to connect to a remote host and, from there, execute code. Hence, code execution.
https://en.wikipedia.org/wiki/Remote_Desktop_Protocol
See also this: https://en.wikipedia.org/wiki/Windows_Remote_Management (different player, same thing)
What on earth are you talking about? RDP and AD are pretty much orthogonal to each other. You can use an AD account to connect to a domain-joined remote server over RDP, but at that point you're just... logging into a machine, same as any other remote protocol. You prevent bad actors from doing this by not giving them permissions to log in to that server. To call this "code execution" is really odd. Remote code execution as a vulnerability almost always refers to an unintentional behavior in software that allows an attacker to execute arbitrary code as part of that process. Referring to a user logging into a machine with the appropriate permissions and running software as "code execution" is not typical, and is not a vulnerability in any normal sense of the term.