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

[A.L.M.Buxey at lboro.ac.uk]

Hi,

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

at some point, the server needs to read passwords... if you have to have a master key, IT needs to be in the config somewhere.
and if someone malicious has control of your server then they could read that key and, using the very PERL libraries
you are talking about, extract the keys.    basically, a server doing RADIUS needs to be secure.

> 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). 

thats really good for when the server restarts after a power cut, outage etc.  almost all people usign apache strip
the key from their server cert for exactly this same reason - you want the server to start up without a human
being around

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

what passwords are you talking about?   user passwords should never be stored in plain text format anyway...as for the
certs, ALL RADIUS servers work in the same way as RADIATOR - ALL of them have a certificate that needs to be read
and someone has access to. 


alan