Il giorno martedì 11 luglio 2017 17:22:11 UTC+2, Federico Capoano ha scritto: > > Hi everyone, > > 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. > > 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. > > Here is a rough summary of the steps needed to configure *rlm_rest *with > freeradius 3: > > 1. install freeradius 3 including the package freeradius-rest > (debian/ubuntu) > 2. enable the module rlm_rest by symlinking, eg: ln -s > /etc/freeradius/mods-available/rest /etc/freeradius/mods-enabled/rest > 3. configure the rest module correctly, here's a sample configuration > I've used to perform my tests > <https://gist.github.com/nemesisdesign/c72d53d5c9bbfee4c03f1f2cb9afc7cb> > 4. configure the default site (/etc/freeradius/sites-enabled/default) > appropiately, here's a sample configuration I just uploaded on > gist.github.com > <https://gist.github.com/nemesisdesign/3b0b55ed9c33828492b9a01b7e216bf6> > > *Conclusion and next steps* > > If there are no objections I suggest to start immediately working on the > RESTful API of django-freeradius, putting the authorization API on top of > the priority list. > > Federico >
It looks a very promising solution. It will buy us: * (at least partial) independency from freeradius database structure * integration with django authentication * support for strong hashes * single source of truth for all things related to the users I think that authorize / authenticate / post-auth are definitely to be ported to rest I wonder if it's worth for accounting / session as they are the most performance (and write) sensitive actions, but we have some time to decide. I'll jump on this during the week-end to have a working environment: let me know if you want to split the workload (or the tests) Iacopo -- 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.
