Microsoft Will Finally Kill Obsolete Cipher That Has Wreaked Decades of Havoc (arstechnica.com) 63
An anonymous reader quotes a report from Ars Technica: Microsoft is killing off an obsolete and vulnerable encryption cipher that Windows has supported by default for 26 years following more than a decade of devastating hacks that exploited it and recently faced blistering criticism from a prominent US senator. When the software maker rolled out Active Directory in 2000, it made RC4 a sole means of securing the Windows component, which administrators use to configure and provision fellow administrator and user accounts inside large organizations. RC4, short for Rivist Cipher 4, is a nod to mathematician and cryptographer Ron Rivest of RSA Security, who developed the stream cipher in 1987. Within days of the trade-secret-protected algorithm being leaked in 1994, a researcher demonstrated a cryptographic attack that significantly weakened the security it had been believed to provide. Despite the known susceptibility, RC4 remained a staple in encryption protocols, including SSL and its successor TLS, until about a decade ago. [...]
Last week, Microsoft said it was finally deprecating RC4 and cited its susceptibility to Kerberoasting, the form of attack, known since 2014, that was the root cause of the initial intrusion into Ascension's network. "By mid-2026, we will be updating domain controller defaults for the Kerberos Key Distribution Center (KDC) on Windows Server 2008 and later to only allow AES-SHA1 encryption," Matthew Palko, a Microsoft principal program manager, wrote. "RC4 will be disabled by default and only used if a domain administrator explicitly configures an account or the KDC to use it." [...] Following next year's change, RC4 authentication will no longer function unless administrators perform the extra work to allow it. In the meantime, Palko said, it's crucial that admins identify any systems inside their networks that rely on the cipher. Despite the known vulnerabilities, RC4 remains the sole means of some third-party legacy systems for authenticating to Windows networks. These systems can often go overlooked in networks even though they are required for crucial functions.
To streamline the identification of such systems, Microsoft is making several tools available. One is an update to KDC logs that will track both requests and responses that systems make using RC4 when performing requests through Kerberos. Kerberos is an industry-wide authentication protocol for verifying the identities of users and services over a non-secure network. It's the sole means for mutual authentication to Active Directory, which hackers attacking Windows networks widely consider a Holy Grail because of the control they gain once it has been compromised. Microsoft is also introducing new PowerShell scripts to sift through security event logs to more easily pinpoint problematic RC4 usage. Microsoft said it has steadily worked over the past decade to deprecate RC4, but that the task wasn't easy. "The problem though is that it's hard to kill off a cryptographic algorithm that is present in every OS that's shipped for the last 25 years and was the default algorithm for so long, Steve Syfuhs, who runs Microsoft's Windows Authentication team, wrote on Bluesky. "See," he continued, "the problem is not that the algorithm exists. The problem is how the algorithm is chosen, and the rules governing that spanned 20 years of code changes."
Last week, Microsoft said it was finally deprecating RC4 and cited its susceptibility to Kerberoasting, the form of attack, known since 2014, that was the root cause of the initial intrusion into Ascension's network. "By mid-2026, we will be updating domain controller defaults for the Kerberos Key Distribution Center (KDC) on Windows Server 2008 and later to only allow AES-SHA1 encryption," Matthew Palko, a Microsoft principal program manager, wrote. "RC4 will be disabled by default and only used if a domain administrator explicitly configures an account or the KDC to use it." [...] Following next year's change, RC4 authentication will no longer function unless administrators perform the extra work to allow it. In the meantime, Palko said, it's crucial that admins identify any systems inside their networks that rely on the cipher. Despite the known vulnerabilities, RC4 remains the sole means of some third-party legacy systems for authenticating to Windows networks. These systems can often go overlooked in networks even though they are required for crucial functions.
To streamline the identification of such systems, Microsoft is making several tools available. One is an update to KDC logs that will track both requests and responses that systems make using RC4 when performing requests through Kerberos. Kerberos is an industry-wide authentication protocol for verifying the identities of users and services over a non-secure network. It's the sole means for mutual authentication to Active Directory, which hackers attacking Windows networks widely consider a Holy Grail because of the control they gain once it has been compromised. Microsoft is also introducing new PowerShell scripts to sift through security event logs to more easily pinpoint problematic RC4 usage. Microsoft said it has steadily worked over the past decade to deprecate RC4, but that the task wasn't easy. "The problem though is that it's hard to kill off a cryptographic algorithm that is present in every OS that's shipped for the last 25 years and was the default algorithm for so long, Steve Syfuhs, who runs Microsoft's Windows Authentication team, wrote on Bluesky. "See," he continued, "the problem is not that the algorithm exists. The problem is how the algorithm is chosen, and the rules governing that spanned 20 years of code changes."
Ah, microsoft... (Score:5, Informative)
Is "retiring" the RC4 a decision of Microsoft that was good if desperately late? Nope, it is a response to someone asking the FTC to investigate why a source of many problems is still in use after so many decades:
https://www.schneier.com/blog/... [schneier.com]
"the problem is not that the algorithm exists. The problem is how the algorithm is chosen, and the rules governing that spanned 20 years of code changes."
LOL, the algorithm was chosen because it made moving people off NT4 domains to AD back 25 years ago "easy". And that time was the time when Microsoft was desperate to block the massive Linux inroads into the server business, so anything was good.
In short, this is microsoft being the bad ole microsoft and nothing else.
Re: (Score:2)
the algorithm was chosen because it made moving people off NT4 domains to AD back 25 years ago "easy".
That's a plausible reason to have it.
But it should've come disabled by default and with a warning label: "RC4 has known issues, enable it only if you have to."
This way, companies upgrading existing networks would turn it on knowing they will eventually turn it off, and companies starting all-new networks (e.g. new companies) could start things off with RC4 off by default.
Re: (Score:3)
This way, companies upgrading existing networks would turn it on knowing they will eventually turn it off
Really? Turn it off and some old but critical piece of gear fails. Quick! Turn it back on.
Years later: Does anyone know why this crufty piece of garbage is still enabled? No? Turn it off. Again, some old but critical piece of gear fails. Rinse and repeat.
Re: (Score:2)
Well, it's not impossible to ask. You'll just hear a lot of "No".
Quite a few companies run expensive software or hardware past the vendor's listed end-of-life date. Not everyone, possibly not a majority--but enough to cause problems. Vendors try to discourage this as much as possible.
The vendor doesn't want to provide software/firmware support forever. Money isn't an argument. If you're willing to pay for support, they know you'll pay regardless of whether the product is old or new. So they choose to make m
Re: (Score:3)
IIRC RC4 was dead in the water not a year after it was announced and leaked in the wild in the mid-90s. Whoever developed Win NT certainly had options.
But it should've come disabled by default and with a warning label: "RC4 has known issues, enable it only if you have to."
This isn't any less irresponsible, though and it would not have flown. The companies that used NT and the later server windows series bought them for the network functionality and 99% of them were, are and will be unable to produce a replacement encrypted authentication and authorization, because it ain't their business. It is the job of the vendor.
How well w
Re: (Score:2, Flamebait)
Indeed. RC4 never got the maturity that anybody competent would have used is. But MS never did "competent".
Re:Ah, microsoft... (Score:4, Interesting)
Actually, thinking back, there was one thing that may have also influenced their choice of approach and influenced this debacle.
If you recall this sad episode of stupid, around 1995 the US decided to introduce "export restrictions" on cryptography, so for a while people were doing all kinds of tricks to walk around these. Eventually the US figured out the obvious - that restricting cryptography only creates problems - and rolled the stupid back.
But while that may explain the choice it hardly excuses it and it definitely does not excuse keeping RC4 in place for another 2 decades.
Re: (Score:2)
But while that may explain the choice it hardly excuses it
Hell, it may have actually been done to force it, in order to bolster America's espionage programs both at home and abroad.
Re: (Score:2)
Could be, there were a lot of rumours about the beneficial advice provided by the NSA to people implementing crypto in software.
Re: (Score:2)
The NSA offered suggestions during the development of DES that secured it against cryptanalysis attacks which were not known to the public. So, the US government helped at least once. They provided feedback to NIST during the selection process for AES algorithms too.
Decades later, that cryptanalysis method was discovered by people outside the NSA, and they put the pieces together. That's how we know about their contribution now.
We have no new information about their input into the selection of Rjindael for
Re: (Score:2)
"RC4 has known issues, enable it only if you have to."
Translated: "Geekspeak geekspeak geekspeak, turn this off and half your devices won't talk to your AD server any more".
Re: (Score:3)
Yep. MS is decades late and was essentially forced to do this.
Why are they still in business, again? And how are regular developers expected to get it right, when they see messed-up stuff like this made by a major player?
Sales rule #37 (Score:2)
The quality of a product is not nearly as important as the quality of its marketing.
Re: (Score:2)
If you want to make tons of money? Sure. If you want to make this planet a better place or at least not a worse one? No.
Re: (Score:2)
Why wouldn't they be in business? Postulate an alternative for us, and make a business case, then sell it to people. When you fail to do what high paid consultants have also failed to do, you'll understand why they are in business.
Clearly the world cares about something else than insecure cyphers.
Re: (Score:2)
Re: Ah, microsoft... (Score:2)
"the problem is not that the algorithm exists. The problem is how the algorithm is chosen, and the rules governing that spanned 20 years of code changes."
LOL, the algorithm was chosen because it made moving people off NT4 domains to AD back 25 years ago "easy"
They're talking about the algorithm that decides what cipher to use for key exchange, and AES has been supported for a while already. I know efforts to migrate from RC4 have been ongoing for a long time. It's a little late and pointless to be salty about cipher choices back in the early 2000s.. the web was barely even using https back then, asymmetric encryption was still "expensive".
For example, user accounts in windows will use AES by default, but if you create a service account you have to manually set t
Havoc == rekt (Score:5, Informative)
Re: (Score:3, Funny)
For all intensive purposes, it's the same thing, but thank you for trying to nip this in the butt.
The headline might get updated, making your post mute, but there isn't much to loose by trying.
Re:Havoc == rekt (Score:5, Funny)
Irregardless, I could care less.
Re: (Score:2)
Re: (Score:2)
For all intensive purposes, (Score:1)
That should be "intents and purposes".
Re: (Score:3, Funny)
I think you meant to say "indents and porpoises".
Re: (Score:2)
That should be "intents and purposes".
And that should be "whoosh", not "wish" - as in "I whoosh I had been paying more attention to that sound just over my head in the moment before clicking on the Submit button".
Re: (Score:2)
Re: (Score:2)
TBF, many man-decades were wrecked fixing the WIndows security problems.
Re: (Score:2)
TBF, many man-decades were wrecked fixing the WIndows security problems.
You mean Windows wreaked wreckage on security?
Re: (Score:2)
Putting in mildly.
Re:Havoc == rekt (Score:5, Funny)
for all intensive porpoises, yes.
Re: (Score:2)
Stop wrecking a nice beach (or perhaps I should say stop wreaking a nice beach?)
Re: (Score:2)
You really mean "wrought havoc". Just adding 'ed' on the end of a verb to make a past participle is lazy, particularly when one already exists.
Re: (Score:2)
You really mean "wrought havoc". Just adding 'ed' on the end of a verb to make a past participle is lazy, particularly when one already exists.
According to my source, wreak came from an Old English word meaning, among other things, to avenge or to gratify one's anger. The same source says that wrought is the "past-participle adjective from Middle English werken"; that Middle English word gives us our modern English word work. Sources: https://www.etymonline.com/sea... [etymonline.com] and https://www.etymonline.com/wor... [etymonline.com]
The words wrought and wreaked may have had common roots farther back in history; but I haven't yet found anything which supports your contention
In related news ... (Score:1, Redundant)
Re:In related news ... (Score:4, Funny)
Just think of all the Havoc that was Wrecked by having RC4 at all. We are taking Microsoft, they could have just put all usernames and passwords in a plaintext ini file.
Re: (Score:2)
Just think of all the Havoc that was Wrecked.
When you "wreck" havoc, aren't you breaking or demolishing it, thereby negating and to some extent reversing it?
In normal usage, one wreaks havoc.
SHA-1? Why?? Not secure enough any more (Score:2)
Re: (Score:2)
Agreed. The default should be the strongest encryption by default. Let administrators downgrade if needed to the highest level that all the dependent tools and connected systems support. If one tool or connected system is the only reason you are using a lower encryption method, it should be documented in the replacement plan so you know when you can upgrade the encryption.
Re: (Score:2)
Sometimes you need to perform cheap and fast hashing for reasons that don't involve security.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There are too many ways known to attack SHA-1. Why can't they at the least use SHA-2? Even better, go straight to SHA-3.
You could use MD4 for all it matters and it would make zero difference. No hash is broke bad enough to compromise a keyed HMAC. Key entropy is by far the weakest link.
OpenBSD is free (Score:2)
So why pay more to get less with Microsoft?
Re: (Score:2)
Lack of braincells and/or defective neural network at one point or another.
Re: (Score:2)
Re: (Score:2)
Originally I wasn't making a serious argument and more of just a funny quip. But I'll bite:
Per machine licensing, service contracts, certification programs, a large suite of costly add-on applications, different licensing for VMs, licensing limits on number of CPU sockets, etc.
I'm going to guess that a Microsoft-based deployment is going to be quite a bit more costly than OpenBSD. Especially in data center and SOHO server where a relatively barebones OS is going to be able to meet the mission requirements.
Wreck or Wreak? (Score:1)
Re: (Score:2)
The phrase is "wreak havoc", not "wreck havoc", sigh.
The number of times I've seen this misused recently has skyrocketed. I think we might have lost this one.
It was so bad (Score:2)
Even Ron Rivest wouldn't give his name to Rivist Cipher 4
"security through obscurity" (Score:2)
ah yes, that. Don't DO that.
Anything that can be destroyed by public review deserves to be destroyed by public review.
So if you're afraid of releasing your security code, your code is probably TRASH.
Chaos Manor (Score:2)
Kerberoasting NOT solved (Score:4, Informative)
Disabling RC4 is a deflection from Microsoft's refusal to deploy secure authentication and authorization technology such as ZKP.
This does NOT solve the problem it merely increases the cost of Kerberoasting roughly 1000x (No thanks to anything inherent in RC4 vs. AES) this increase means very little in terms of real world outcomes where this type of scaling is the difference between spinning up more threads on more systems or waiting hours or days instead of seconds and minutes.
Article is wrong (Score:2)
Nope. It is short for Ron's Code 4 [mit.edu]
Wreaked not Wrecked Havoc (Score:2)
Wreak (Score:2)
Wreck vs wreak. Illiterate editors.
Think of the APTs!! (Score:1)