Hi Nadav, You're wrong. Please educate yourself about what a security boundary is.
Kind regards, Nick On Tue, Oct 6, 2015 at 12:06 PM, Nadav Hod <nadav....@comm-it.co.il> wrote: > Hi, > > The password doesn't need to be in plaintext in the configuration, it can > simply use an alias system so that if I send the argument "router123" then > router123's password will be copied to memory securely, where it can then be > used. Same goes for any passphrases for accessing certificate stores. This is > how kpcli works, you supply string1 and you get back password1. > > I think there is merit in changing the existing configuration files from > using "router123,mypassword" to something like GetPassword(%UserName). It > seems more secure to me and not because of obfuscation but because the > interface with Radiator itself is more secure. It also doesn't expose > credentials nearly as much as the status quo. At no point in any of the > configuration files and databases should credentials be left in unguarded > cleartext, it's just not technical limitation these days. > > I'm unsure why there isn't any interest from anyone in this mailing list > other than myself to secure these credentials. Let's look at other solutions. > I heard a suggestion to use TPM, but that's hardware-specific and also > depends on how the encryption software supports its use. > > Would using Microsoft EFS on the Radiator folder (which contains all NAS > credentials) and limiting access be a stronger solution than using an > encrypted database? Would this cause a noticeable performance hit for an SMB? > > ________________________________________ > From: Christian Kratzer [ck-li...@cksoft.de] > Sent: Saturday, October 03, 2015 4:06 PM > To: Nadav Hod > Cc: Tuure Vartiainen; radiator@open.com.au > Subject: Re: [RADIATOR] Password/certificate security seems next to none > on Radiator server > > Hi, > > On Fri, 2 Oct 2015, Nadav Hod wrote: >> Hi Tuure, >> >> Moving the secrets from one cleartext file to another isn't secure, it's >> just a way to break the code between more files. > > you still clearly do not understand that there is no way to solve this in > software. > > Not in radiator or in any other software. > > Radiator or any other radius server needs to keep in plaintext: > - credentials it needs to connect to backend databases > - possible certificate private keys or passphrases to unlock those when needed > - radius secrets > - ... > >> I'm interested in a secure way to access credentials which are kept both >> encrypted and only accessed when authenticated by a keyfile or something >> equally strong. > > If credentials are kept encrypted and are decrypted on demand that is equally > just obfuscation. > > You asked for it and were shown a way how to accomplish this but rejected it. > >> As far as I can tell this doesn't exist today in Radiator, I'm asking this >> members in this mailing list whether or not they think there is added value >> in implementing some form of sustainable security for these credentials. > > Radiator is following best practices already. > > Greetings > Christian > > > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
