There’s a lot of misinformation circulating about the BlastRADIUS vulnerability. For us, as RADIUS experts, it’s a depressing reminder of how little people understand about this foundational protocol that underpins so many network interactions. But for a CIO, CISO, system administrator, or network technician, this bad advice is dangerous.
Let’s set the record straight on a few of the ill-informed suggestions we’ve seen since BlastRADIUS broke on July 9. Follow along to learn why alternatives like TACACS+ and Diameter won’t work; why lowering time-outs is not the answer; and why switching hash algorithms doesn’t help.
What does help? Download the new RADIUS firmware/packages, and upgrade. You'll be fine.
TACACS+ and Diameter won’t help with BlastRADIUS
There are several protocols that perform what seem to be similar functions to RADIUS, but in reality, none of them can replace RADIUS’ core functions.
Not TACACS+, not IPSec, not Kerberos. RADIUS is a gatekeeper protocol, allowing access to a network, while these other protocols authenticate and authorize systems when you already have network access.
They are not interchangeable, and it is disappointing that some cyber security organizations would suggest them as alternatives.
The team at InkBridge Networks has decades of practice with RADIUS and other networking protocols. We can confidently say there is no viable alternative to RADIUS right now, and the steps to protect your system from BlastRADIUS are not onerous.
The paper by the researchers who found the BlastRADIUS exploit also notes that TACACS+ and Diameter are not suitable alternatives to RADIUS. TACACS+ is a popular (TCP-based) administrator login protocol for switches, but it also does not meet modern cryptographic security standards. The researchers state that TACACS+ is most commonly used over insecure transports, much like RADIUS. RFC 8907 from September 2020 explicitly mandates that TACACS+ be used with a secure transport.
In some limited cases (administrator authentication to devices), TACACS+ and RADIUS overlap, but switching to TACACS+ is more difficult than just upgrading the RADIUS server (and then you're protected).
Although designed as a successor to RADIUS, Diameter never replaced RADIUS for many common use cases. It is inappropriate as a solution to BlastRADIUS for most enterprises because it is generally only supported in large NAS equipment used by bigger ISPs and telecommunications providers. Consumer or enterprise-grade equipment typically does not support Diameter.
Don’t change timeouts and hash algorithms
Lowering timeouts isn't an option. It does nothing to prevent an attack. The attacker just spends a little more money and completes the attack more quickly.
In the words of the researchers who found BlastRADIUS: “It is tempting to hope that simply setting a client timeout below our reported MD5 collision running times would defend against our attack. We believe this should not be done: it decreases usability and does not protect against our attack.”
We’ve also seen suggestions to switch hash algorithms as a response to BlastRADIUS. In our view, switching hash algorithms (e.g. MD5 to SHA256) is the wrong approach when RADIUS/TLS is already defined. The vulnerability exists because of RADIUS’ "ad hoc" packet authentication construct, not because of MD5. While MD5 makes the attack easier, the underlying construct is still vulnerable even with other digest methods. So, switching to SHA256 doesn't help.
In the short term, here’s a much better alternative than SHA256 – switching authentication constructs to an HMAC with the Message-Authenticator attribute. RADIUS servers already support Message-Authenticator, and most clients support it. They just have to be configured to require it for Access-Request packets.
The bottom line
Please don't believe anyone who recommends the above mitigations. The suggestions are wrong. They won’t help. Trying to use one of the bad suggestions will just result in frustration and wasted time.
If the aim is network security, then stick with RADIUS, and do the work to upgrade your devices. Don't redesign your network. Don't switch to alternatives that won’t do the job. Above all, don’t brush this off because it seems like a difficult attack to accomplish. It could be one step in a daisy chain that leads to a catastrophic breach, but that’s a philosophical debate for another time.
To fix the BlastRADIUS vulnerability in RADIUS, follow the steps outlined in our BlastRADIUS upgrade guide. You’ll be protected without upsetting other network functions. If you’d like help from the people who know RADIUS best, we offer further tools and ongoing support here.
Need more help?
InkBridge Networks has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.
Related Articles
RADIUS protocols and password format compatibility
In order for RADIUS authentication to work, user passwords need to be stored in a format that is understood by the authentication protocol used by the client. Unfortunately, not all protocols work with all password storage formats. This can be especially problematic with platforms that use proprietary formats or protocols.
How Authentication protocols work
There are a variety of authentication protocols to choose from, each with their own set of advantages, disadvantages, and constraints. In general, we recommend using PAP whenever possible. It is compatible with all known back-end databases, and it has no known security issues.