Hi Leonardo, On Thursday, July 13, 2017 at 7:46:26 AM UTC+2, leonardo.maccari wrote: > > > On 11/07/17 17:21, Federico Capoano wrote: > > Hi everyone, > > > Hi Federico, > > I have looked into FreeRadius (FR) in the past, so I am curious about this > issue. > > I have found a possible solution for the hash algorithm, let's recap for > those who don't know what we are talking about. > > *Problem* > > Freeradius many different authorization and authentication schemes but > when it comes to the hashing algorithm used for passwords choices are > limited, the stronger hashing algorithms being md5, sha1 and unix crypt. > > > What is exactly the hash you are referring to? If I understood correctly > it is the hash used to encrypt passwords in the database, which is not > mandated by FR but from the (inner) method you configure FR to use: > > http://deployingradius.com/documents/protocols/compatibility.html > > Yes you have understood correctly, we are talking about the password hashing algorithms supported by Freeradius.
> basically, if you want to use any of these authentication protocols, you > have to use these hashes because the password comes already hashed from the > supplicant. If you want to use another hash you have to configure FR to > pass along the password in clear, and then do your own hashing. You can do > this using the PAP protocol, which sends the password in clear (!!) and > then you can hash it at the destination. To make this reasonably secure you > have to embed it into a TTLS tunnel. This may be even supported by other > applications so you can re-use the db for other uses. > > We don't want to use one of those hashing algorithms for the reasons stated in the first email. The password can then be sent to freeradius in cleartext using a TTLS tunnel. In some cases, the NAS (network access server) sits on the same host of freeradius or in a trusted LAN (eg: the LAN of a virtualized physical server) and a TTLS tunnel is not needed. > > Unfortunately these algorithms are rather obsolete and we would much > rather let Django handle this for us because it does it pretty well . > Django nowadays uses PBKDF2 <https://en.wikipedia.org/wiki/PBKDF2> by > default and allows for even stronger algorithms, see the Password > Management <https://docs.djangoproject.com/en/dev/topics/auth/passwords/> > documentation on the django website for more information. > > To use the default freeradius setup would mean downgrading our own hashing > algorithm and I think this is unacceptable for several reasons: > > - it's 2017, MD5 is easy to break and SHA1 has just been demonstrated > to be crackable by Google and other big players > - we really didn't like that in OpenWISP1 each module has its own > database of users, infact we hated it; > our aim is to have a single (distributed) database of users shared > between the different openwisp2 modules and we really want > django-freeradius to become an important module of openwisp2, therfore > downgrading the hashing algorithm for django-freeradius means downgrading > it for the entire openwisp2 ecosystem: definitely not viable! > > *Solution* > > The recommended solution in these cases is to delegate authorization and > authentication to a separate application, in our case this can be handled > by django-freeradius itself. > > *rlm_exec* > > The first solution I have tried is to configure freeradius 3 to use the > *exec* module call a unix/linux script during the authorization phase, > the script gets passed the username and password and if the combination is > correct exits with 0 (zero) otherwise it exits with 1 (which means failure). > This solution works but has two problems: > > - freeradius runs as a user (freerad in my test environment) which has > very limited permissions and can't easily access the python virtualenv of > django-freeradius, infact I had to perform some ugly hacks to make this > script work > - this method is not recommended by the freeradius community because > according to them it doesn't scale well, they suggest to use the > *rlm_rest* module > > *rlm_rest* > > This module allows to configure freeradius to delegate some or all of its > operations (authorization, authentication, accounting, postauth) to a REST > API. > > I've successfully configured my test freeradius instance to authenticate > and authorize using an existing REST API and it seems to work very well. > > Since this method is recommended by the freeradius community and allows > great flexibility, I believe we should go along this path: we should > implement a few simple API endpoints that are dedicated to freeradius, > starting with authorize. > > > Again, if I understood well, you are actually giving FR an API that plugs > back into django? then, why are you using FR at all? I suppose your use > case is to have one FR instance that serves several services, such as > openwisp, but this way you can't decouple FR from django. > We want to let freeradius do what is good at doing: speak the RADIUS protocol to perform AAA with popular networking software (captive portals, WPA enterprise). Freeradius can read /write from/to one or more datastores to retrieve/log data about authorization, authentication and accounting, SQL is just one of the several datastores supported by freeradius. Other datastores supported are redis, couchdb, a REST API, an external program and some more. Using a REST API built purposely for freeradius we can let freeradius focus on speaking the RADIUS protocol with other networking software and equipment while we can handle all the application level details autonomously overcoming limitations that would make the application less useful in the long term. We can say that two pieces of software are highly coupled when both know many specific details about each other, in this design freeradius doens't know anything about django because it limits itself to sending DATA via HTTPS according to its configuration and expects a response in a specific format. It can be reconfigured any time. If someone changes their mind and wants to migrate to a different radius management solution they can just migrate the data and reconfigure their freeradius instances to speak to a different URL or they can reconfigure it entirely to use SQL queries or other datastores. I hope is clear. If not, let me know. Federico -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
