Log InAs we’ve previously discussed, there are several insecure elements in RADIUS. We are currently working in the IETF (Internet Engineering Task Force) to close those gaps and improve security for everyone. This article outlines some of the current shortcomings of RADIUS, best practices for mitigating against them, and a roadmap for how these vulnerabilities will be addressed within the RADIUS standard.
Information is sent “in the clear”
The most obvious shortcoming of RADIUS is that, other than a few attributes such as User-Password, all information is sent “in the clear”. This means that things like users’ location data and device MAC addresses, among others, are sent in clear text across the network. This has obvious privacy and security implications when UDP is used across the Internet.
What to do about it right now
The first step is to stop using insecure transports such as UDP and TCP for RADIUS traffic. Instead, we strongly recommend using TLS. An issue that affected RADIUS/TLS in version 3 of FreeRADIUS was resolved earlier this year, so the transition from UDP to TLS should be straightforward. If using certificates is too hard, we recommend using TLS-PSK. Administrator overhead for TLS-PSK is not substantially higher than for shared secrets, and TLS-PSK offers significantly increased security and privacy.
Looking ahead
Another way of increasing privacy with RADIUS is to minimize the amount of PII (Personal Identifying Information) which is sent in packets. Where possible, identities should be anonymized using the Chargeable-User-Identifier. Other information such as device identity, user location, and visited networks should be omitted, anonymized, or replaced. A more detailed discussion of these issues can be found in our IETF Draft
MD5 has been broken
The security of RADIUS relies on an MD5 signing of the packet using the shared secret. Unfortunately, MD5 has been broken for over a decade. GPUs have gotten faster, which means that administrators should assume that when RADIUS/UDP packets are sent over the Internet:
- any shared secret of 8 characters or less has been immediately compromised.
- any shared secret of 10 characters or less has been compromised by an attacker with significant resources.
- any private information (such as User-Password) which depends on a cracked secret has also been compromised.
What to do about it right now
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 2023.
For internal use in management networks, RADIUS/UDP can be acceptable. But the RADIUS traffic should be isolated from all other network traffic, ideally via a VLAN or an IPSec connection. If you must use RADIUS/UDP in any context, we recommend using strong shared secrets. Use at least 32 characters, and take the shared secret from a cryptographically strong pseudo-random number generator.
Looking ahead
One of the biggest barriers to sending RADIUS traffic using TLS instead of UDP is that many NAS hardware devices do not support this functionality. As seen in our document, the IETF is mandating that TLS-based transport layers be used for RADIUS traffic outside of secure networks. This document will become an IETF standard in the near future. We hope that these new requirements will push NAS vendors to make RADIUS/TLS available in their products.
Short shared secrets have been compromised
Because of the ease of cracking MD5, administrators should assume that all short shared secrets have been compromised by anyone who can see RADIUS/UDP traffic.
What to do about it now
You should immediately change all short shared secrets to ones that have at least 32 characters (we recommend 64). It is very easy to create long shared secrets. One way of doing this is the following script:
#!/usr/bin/env perl
use MIME::Base32;
use Crypt::URandom();
print lc encode_base32(Crypt::URandom::urandom(24)), "\n";
Given the simplicity of creating strong secrets, there is no excuse for using weak shared secrets with RADIUS.
Additionally, we repeat that you should send RADIUS traffic over TLS, rather than UDP.
Looking ahead
This cannot be fixed as it is a fundamental design flaw in the RADIUS protocol. We can only “paper over” the issue by using RADIUS/TLS.
Secure storage of passwords
The authentication protocol used for RADIUS has knock-on effects for the related systems that use it. Specifically, we recommend that the PAP protocol be used because it allows passwords to be stored in the database in salted/encrypted form. They are in clear-text only temporarily in the memory of the RADIUS server which receives and then verifies the password
By contrast, using CHAP or MS-CHAP instead of PAP means that the passwords must be stored in clear text in the database, all of the time. Any compromise of the application means that the entire database can be immediately read and exfiltrated as a whole. The attacker then has complete access to all user identities, and all associated clear-text passwords.
Given that the vast, vast, majority of breaches consist of database attacks, the risk of password compromise is much less with PAP than with CHAP or MS-CHAP.
What to do about it now
If possible, make sure that you are using the PAP authentication protocol. Store passwords securely in a database.
Looking ahead
We cannot mandate which authentication protocols are used, but we will continue to strongly recommend using PAP for the foreseeable future.
MS-CHAP is broken
In addition to the vulnerability described above regarding the storage of passwords, MS-CHAP is also deeply flawed and should be considered an insecure protocol.
Recent developments have demonstrated that it is possible to crack MS-CHAP exchanges with consumer hardware within milliseconds. This means that for all intents and purposes, any MS-CHAP exchanges that are sent using UDP or TCP transports should be considered compromised.
What to do about it now
Our first recommendation is always to use PAP instead of MS-CHAP. However, if this is not possible, MS-CHAP should always be used within TTLS, PEAP, or RADIUS/TLS.
Looking ahead
In our proposed IETF standard, we are deprecating insecure transport protocols for RADIUS and will be mandating that MS-CHAP authentication data carried in RADIUS must not be sent over UDP or TCP
To summarize
The key take-aways from this summary are as follows:
- Stop using insecure transports such as UDP and TCP. (mandated in upcoming new standard)
- Use long shared secrets, at least 32 characters (mandated in upcoming new standard). 64 characters are preferred (recommended)
- Use PAP instead of CHAP or MS-CHAP as the authentication protocol (recommended)
- If MS-CHAP must be used, it must be sent across a secure transport such as TLS (mandated in upcoming new standard)
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.
