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