RADIUS is almost thirty years old, and uses cryptography based on MD5. Given that MD5 has been broken for over a decade, what are the implications for RADIUS? Why is RADIUS still using MD5?

RADIUS still uses MD5 because there are hundreds of thousands of devices which implement RADIUS. It is difficult and expensive to ugrade all of these devices to use a new protocol. Even though RadSec is a decade old, it still is not widely supported in NAS equipment!

That needs to change. One way to change it is to raise awareness about the insecurity of the RADIUS protocol, which is why we are writing this article. Another way is to update the RADIUS standards to officially deprecate the use of RADIUS/UDP, which is why we are working on an IETF document called Deprecating RADIUS.

What’s so bad with UDP?

Most RADIUS traffic is sent “in the clear”. This means that RADIUS can leak all kinds of private information, such as names, location, device identities, etc. If you’re OK with governments snooping the net and knowing everything about you, this isn’t a problem. If you want to maintain your privacy, this is an issue.

Systems like Eduroam use RadSec (or RADIUS/TLS) everywhere. This is a great design for security and privacy. However, there are a number of “cloud RADIUS” providers who send RADIUS packets over the net, using just UDP. This practice is bad for security and bad for privacy.

Just how bad? Very bad. Very, very, very bad.

Breaking RADIUS

While MD5 has been broken for over a decade, no one has published an analysis of just how bad the problem is for RADIUS. In this article, we will do a bit of math (it’s not that hard), to see how long it would take to “crack” RADIUS shared secrets. It’s a lot shorter than you might think.

We will assume that the shared secret uses uppercase and lowercase letters, numbers, and a few “special” characters. This assumption gives us 64 possible characters to use. For 8 character secrets, there are 2^48 possible values of the shared secret.

The security of RADIUS depends on a hash which is calculated as MD5(packet + secret). This construction means that an attacker does not have to calculate the full MD5 over the entire packet each time. Instead, the attacker can just snoop one Access-Accept packet, do some preliminary work to hash it, and then run full-speed trying shared secrets.

Modern CPUs and GPUs can do many, many, MD5 hashes per second. Reasonable numbers for “off the shelf” hardware (2022) are 100M hashes per second for a laptop CPU, and 64B hashes per second for a high-end GPU. Some math then shows that all 2^48 possibilities for shared secrets can be checked in about 32 days on a laptop, and about ninety minutes on a GPU.

The problem doesn’t get much better if the character set is expanded to include all printable ASCII characters (about 93 characters). A bit more math shows that this problem is harder, but the entire 8 character shared secret space can be searched in about a day on a high-end GPU.

Increasing the password length helps a bit. If we increase the shared secret length to 10, then the entire shared secret space (of 64 characters) can be searched with one GPU in six months. The picture is slightly better with a set of 93 possible characters, it now takes 24 GPU years to search all possible 10 character shared secrets.

These numbers sounds reasonably secure, but they are not swecure against attacker with money, such as a nation-state. If a national goverment wishes to crack your RADIUS shared secret, then the cost of 24 GPU years is a drop in the bucket to them.

What does this mean?

These results should scare anyone who is using RADIUS/UDP over the wider Internet. It is simply not secure. The following statement explains just how bad that practice is.

Administrators should assume that any shared secret of 8 characters or less has been immediately compromised. Administrators should assume that any shared secret of 10 characters or less has been compromised by an attacker with significant resources. Administrators should also assume that any private information (such as User-Password) which depends on a cracked secret has also been compromised.

Note that the above statement only applies to RADIUS/UDP being sent over the public network. If your system uses RADIUS/TLS (RadSec) such as with Eduroam or OpenRoaming, then you are fine. Your systems are secure.

What should I do?

First, don’t send RADIUS/UDP traffic across the Internet. It was a terrible idea ten years ago. It is incredibly irresponsible to do that in 2022.

If you must use RADIUS/UDP in any context, we recommend using strong shared secrets. While your network may be secure today, a misconfiguration or an attack could result in someone seeing your RADIUS traffic. Which would break all of your network security, for all of your users.

It is much better to generate shared secrets using a source of secure random numbers, such as with the following script:

#!/usr/bin/env perl
use MIME::Base32;
use Crypt::URandom();
print join('-', unpack("(A4)*", lc encode_base32(Crypt::URandom::urandom(12)))), "\n";

This script will generate secrets of the form dfxz-ffr3-yx4b-uqyk-om3q. This form of secret will be accepted by any known implementation which supports at least 24 octets for shared secrets. The generated secrets have 96 bits of entropy, which is adequate for the forseeable future against any attacker.

Given the simplicity of creating strong secrets, there is no excuse for using weak shared secrets with RADIUS in any situation.

For internal use in management networks, RADIUS/UDP can sometimes be acceptable. But the RADIUS traffic should be isolated from all other network traffic, ideally via a VLAN or an IPSec connection.

The better approach is to switch all RADIUS traffic to using TLS. That may be a little bit more difficult in the short term, depending on the RADIUS/TLS support in NAS products. If your NAS equipment supports RADIUS/TLS, we recommend using it. Otherwise, we recommend asking your NAS vendor for that functionality.

If you take away one thing from this article, it is the following: Do not send RADIUS/UDP traffic over the Internet. Ever.

Need more help?

Network RADIUS 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.