Plain text shared secrets problematic?
Hi, I'm fairly new to the topic but I got the assignment to find out if the fact that the shared secrets for user logins are in plain-text could be a problem security-wise. Isn't there a way do encrypt them or make the password encryption more secure? I've been researching for some hours now and fould several articles about RADIUS' vulnerabilities, but noone seems to be concerned about this subject. I hope you might be able to clear things up for me. Regards Mathias -- View this message in context: http://freeradius.1045715.n5.nabble.com/Plain-text-shared-secrets-problemati... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 29/03/12 11:46, Heilz wrote:
Hi, I'm fairly new to the topic but I got the assignment to find out if the fact that the shared secrets for user logins are in plain-text could be a problem security-wise.
Do you really mean "shared secrets"? This is a term normally applied to the RADIUS secret used for encrypting/authenticating the radius packets between the NAS and RADIUS server. If this is what you mean: Shared secrets are just that - secret. If they're exposed, then yes, you have problems. No, you can't encrypt them. The plaintext is required to run the crypto. If you feel that use of shared secrets is insecure, then bear in mind two things: 1. RADIUS is an old protocol, and needs to preserve backwards compatibility. 2. However, there is an effort to run radius over TLS, called RadSec. This is supported in "master" (to become 3.0) versions of the server, and some other software such as Radiator, radsecproxy and so forth. Or do you mean the client passwords, such as Cleartext-Password? In which case, you can store them encrypted in certain formats, depending on what auth mechanisms you want - see here: http://deployingradius.com/documents/protocols/compatibility.html
Isn't there a way do encrypt them or make the password encryption more secure? I've been researching for some hours now and fould several articles about RADIUS' vulnerabilities, but noone seems to be concerned about this subject.
If you can be more specific about which "this subject" you mean, it would help.
Thanks for the quick answer. Yes, the RADIUS secret was what I meant. Since we want to use a freeRADIUS proxy in our DMZ and because a secure connection from our customers to our application is important, that seems to be a problem. Are there maybe some best practices for a case like that, or isn't the plain-text secret such an issue after all? -- View this message in context: http://freeradius.1045715.n5.nabble.com/Plain-text-shared-secrets-problemati... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Heilz wrote:
Thanks for the quick answer.
Yes, the RADIUS secret was what I meant. Since we want to use a freeRADIUS proxy in our DMZ and because a secure connection from our customers to our application is important, that seems to be a problem. Are there maybe some best practices for a case like that, or isn't the plain-text secret such an issue after all?
(a) use a plain-text secret (b) install the git "master" branch, and use RadSec. (c) use IPSec for connectivity There are no other choices. Alan DeKok.
participants (4)
-
Alan DeKok -
Heilz -
Phil Mayers -
Thomas Glanzmann