[RADIATOR] Password/certificate security seems next to none on Radiator server

Nadav Hod nadav.hod at comm-it.co.il
Thu Oct 1 08:16:22 CDT 2015


I would like to discuss the issue of securing passwords and certificates on the Radiator server. From looking over the documentation and asking a member of support on the matter, it looks as if there is no option for encrypting passwords in the configuration. Moreover there seems as if there is no option to secure the certificates. I research this for a bit and herein is one possible solution, I'm sure there are others which may be more suitable.


I believe that OSC should look into KeePass, specifically kpcli which is a perl distribution which allows storing passwords in a highly encrypted manner whilst allowing access via master password or a keyfile. You can even make a composite password which requires both a key file and a password (so that even if the keyfile or master password is compromised, your passwords aren't). Two-factor authentication and encryption is much better than no authentication and encryption at all. The key file should be allowed to be accessible from a remote network share.


It's true that the master password would have to appear in the configuration, but the keyfile solution sounds promising if you ensure that the user running the radiusd process is a domain user who has access only to the necessary files and shares. Another option for the master password would be to prompt the Radiator administrator for the master password when radiusd is run (preferably via CLI so that it can be automated). 


As for securing certificates:

How about a way to store the certificates in a keystore such as pkcs12 which is already available via OpenSSL? 
In this way each certificate in the keystore can be addressed by alias, whilst they are encrypted and safe, without having to keep individual passwords in cleartext. 
The passwords retrieved from kpcli could include the password for the keystore as well as certificates within the file, thus providing authentication and encryption to all certificates which Radiator must access.
Anyone who doesn't wish to encrypt their passwords or secure their certificates could continue to work with Radiator the same as before, these are only suggested enhancements.


I can imagine how security administrators would frown upon having passwords in clear text and certificates out in the open (regardless of OS folder security permissions). Saying it's secured by folder permissions doesn't sound like much when CA certificates, passwords and private keys are at stake.


Your thoughts?


More information about the radiator mailing list