Senator Ron Wyden has asked the Federal Trade Commission to investigate Microsoft over its continued use of the RC4 encryption algorithm. The letter talks about a hacker technique called Kerberoasting, that exploits the Kerberos authentication system.
Will Fiveash • September 16, 2025 10:11 AM
Dealing with a crypto algorithm used by Kerberos and found to be weak, as is the case with RC4 (or single DES, etc…), is non-trivial. Kerberos is used in widely deployed scenarios with a potential mix of OS’s (Solaris, Linux, Windows, macOS, etc…) which makes seamless migration of weak Kerberos enctypes (the crypto used by Kerberos) to stronger enctypes a real pain. If you get it wrong, authentication stops working and soon the sysadmins are hearing from all kinds of folks because they can’t get work done. I don’t envy MS software engineers working on these issues.
TimH • September 16, 2025 10:31 AM
Microsoft has form in allowing weaker encryptions. For Bitlocker, they removed the Elephant Diffuser PRNG, and the default is AES-128. Who’d know to change to AES-256 before FDE?
JR • September 16, 2025 11:13 AM
RC4, wow. They had an SSL cert that was signed with RC3 just a few years ago. It was used in their waagent that runs on Linux systems in Azure. Note there are several Azure environments. The env I was using was meant to be secure, but was the last to get any updates. They fixed the Cert in the public Azure and kept tellings us we were wrong,. Their agent wasn’t working correctly when the Linux machines where in FIPS mode.
Wannabe Techguy • September 16, 2025 11:48 AM
Why would any IT pro be surprised by anything M.S. does? With all the issues with Windoze updates,I’m not surprised with their low quality work(laziness?). And yet, people still trust them.
Clive Robinson • September 16, 2025 12:09 PM
@ ALL,
Just a point to note…
RC4 is still a usable algorithm for a number of things including “Communications Whitening”(generating noise) and “for simulation”(like O’l Montie).
However RC4 has like many “simple card shuffling algorithms” passed beyond the point where it can be considered cryptographically secure even for you little sisters diary, now she keeps it on a computer…
I think it safe to say that all crypto algorithms outside of a special class will fall to this issue.
It’s just a matter of when not if.
Which of course brings up the issue of “embedded” and “grid” systems I’ve been mentioning for many years now…
KC • September 16, 2025 3:47 PM
From the man who coined the term Kerberoasting in 2014, Tim Medin also responded to Wyden’s letter and gave Microsoft’s response a little undressing.
As Clive mentioned, AES-based Kerberos tickets are still susceptible to Kerberoasting. According to a benchmark that Tim ran, it was just that AES128 and AES256 tickets were approximately 350 and 700 times slower to crack.
https://redsiege.com/blog/2025/09/kerberoasting-microsoft-and-a-senator/
Blaziken • September 16, 2025 10:15 PM
@Clive
RC4 is still a usable algorithm for a number of things …
Agreed.
Similarly SHA-1 will always live on courtesy of Section 4.2.1.2 of RFC5280, but this should not pose a security issue as a hash collision could only cause trust path construction to fail and should not lead to incorrect certificate validation except in the most broken implementations.
Clive Robinson • September 17, 2025 4:42 AM
@ KC, ALL,
With regards,
“AES-based Kerberos tickets are still susceptible to Kerberoasting.”
And as far as I can work out it should actually be,
“All ways will be…”
This is due to fundamentals in the design (that also effect so many other systems[1]).
But consider, if you change those fundamentals then two things,
1, Not only will it not be Kerberos any more, it won’t be compatible.
2, To make them compatible will open other security vulnerabilities.
3, The new vulnerabilities will almost certainly form classes of attack.
These are things even technical people don’t want to talk about in what is one of the more widely deployed systems of it’s type in the world…
[1] It’s odd that I should be talking about this twice in as many days, but they do say,
“Random things tend to clump”
(Or is it humans 😉
People have to learn a number of painful exercises or suffer the potential consequences.
One such which comes up all to often is “Off line authentication”. The bottom line is to do any type of authentication you need a unique and unforgeable ID-Verifier pair so we have one variety we all know and hate, the all to recognisable “Username and password” and like bank card numbers and verifiers and the PIN number etc etc.
Whilst the ID can be public and often is the verifier should always be a,
“A shared secret”
And this implies not just that it should be unique and unforgeable, but importantly also held private from all but the necessary verification process.
If it’s not then,
“It’s game over.”
So, consider an actually quite common situation of a system where you have users who
“Must be authenticated, but… can not, nor should not, be trusted.”
They have to both “hold and control” but “not know/access” in any way the shared secret…
There are ways that this can be done with a 2-Party On-line system, but Off-line and effectively 3-Party…
It’s why Set-Top-Box and CD/DVD etc for distribution of videos was always going to fail when the “shared secret” became known to the “assumed hostile user”.
This is one of the easier authentication system failures to see and there are oh so many more…
ResearchetZero • September 22, 2025 1:09 AM
Their Entrance ID system is bust too. As the legacy Graoh API did not properly validate the originating tenant, an actor could gain global admin with an “Actor Token” to any AD tenant.
This authorization also allowed modification of settings including user ID, applications and permissions, group, Service Principle etc.
‘https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/
ResearcherZero • September 22, 2025 1:11 AM
*Entra ID. (Spell checker)
Celos • December 16, 2025 1:19 AM
How is anybody expected to make good decisions when they have a major player mess it up this badly, time and again?
We really need IT engineering standards and real penalties that hurt if you do not follow them in a commercial context. Otherwise this mess will go on forever.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Wayne • September 16, 2025 9:47 AM
I was reading about this last week and was quite surprised. Kind of amusing that the world is underpinned by MS, and it turns out it’s a deck of cards. I think a lot of us if asked in the ’90s about something like this, we might have said ‘Yeah, probably.’
Microsoft’s fix timetable really needs to be faster, now that this little disaster is known widely. I wonder what, if any, mitigations can be taken to defend against it.