Password Encryption

[daverickdunn]

Hi guys,

I'm wondering has anyone given thought to, or is it within the scope of the projects goals, to add the respective encryption algorithms for the radcheck passwords and an option to encrypt from the admin panel?

I'm going to have to do this myself anyway, for at least one algorithm, so would be happy to contribute if this is something that is welcomed.

Edit: To clarify, I mean to add an extra field + button to populate the value field with the encrypted password, as seen below:

[nemesifier]

Hi @daverickdunn and welcome, do you want to use this for the authorize phase or for what else?

[daverickdunn]

Hi @nemesisdesign, yes, authorize. Unless I'm misunderstanding something, I'm fairly new to freeradius/radius...

[nemesifier]

@daverickdunn we perform authorize via the rest API and delegate the password encryption to django, which does a much better job than md5/sha1/ecc.

See: http://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#how-to-configure-the-rest-module and https://github.com/openwisp/django-freeradius/blob/master/django_freeradius/api/views.py#L16-L26

If it's not clear, just keep asking and I'll write more details when I have time.

[daverickdunn]

Thanks for the info, I was clearly misunderstanding the purpose of this package - I assumed it was acting simply as an admin interface to a set of FreeRadius tables, and I also assumed the REST API was simply a tool to perform CRUD on those tables.

I agree that Django's auth module is more secure, and it's a great idea to use it instead of the weaker algorithms, there's no question about that, but this morning, after properly implementing and configuring django-freeradius, I think I've run into a fairly large issue: Some embedded systems (specifically MikroTik's RouterOS), don't support sending clear-text passwords.

Certainly that means they cannot be authenticated against the default Django hashes, right?

I'll have to auth several different types of systems against this radius sever, Cambium, Cisco, etc. So I'm anticipating there may be others as well.

Am I missing another trick, or is this really a blocker for authorising these systems using Django?

Cheers.

[nemesifier]

@daverickdunn I see. Most probably those systems expect clear text passwords to be sent over an insecure or untrusted connection, which is not the case of OpenWISP. The architecture of OpenWISP requires to have a trusted secure communication between freeradius, the captive portal (usually PfSense) and the web application.

That said, this project is still a work in progress (you may have noticed the release version is still alpha) and is going to replace an existing project called OpenWISP User Management System (which is also a freeradius web UI). One of the goals of this project is to be more flexible than OpenWISP User Management System and allow more users to integrate it in their systems and hack it, so I think is good to have users like you and @peppelinux that are trying to integrate it in different scenarios.

The authorization via the REST API is not mandatory, so you can implement/configure it differently so that it can work out for you.

I do not love the idea of duplicating the user password in different records which do not have a foreign key to the user model, because that would make the change/reset password operation harder to handle, but in this case I seem to understand that the password is needed to authenticate a device and not a user, have I understood correctly?

If yes, most probably it would not make sense to create different user records for each device and it would be better to use the radius check mechanism.

If you can give us more insight about your use case it would help us reach a better understanding and find a good long term solution.

[peppelinux]

Hi guys, it's nice to hear you on this :) Yesterday I pushed this feature in my repository, as you can see from the next picture I coded an admin form to introduce a new_value field that takes a password in a passwordfield widget and, in according to the password format (cleartext,nt-password....), stores the corresponding hash in the value field.

The password validation is quite strong, according to European GDRP and there's the possibility to disable weaks Password formats like Cleartext-password or preferred ones, in the app.settings. There are also some other password hashes to implement, actually I coded only lm and nt password hashing function.

Now, one of the next tasks, is to introduce some other attributes for the users. I already thought about the opportunity to extend the radcheck schema but I admit that there will be the problem to specialize something that should not be, like the general purpose concept behind radcheck table suggests to us. I thought about the opportunity to introduce an extended adminform to manage radcheck and user extended attributes (email, phone, social,doc_id...), catching all them in a single form and then store them into two separate db table, on save trigger.

There will be also the opportunity to generalize all the things, introducing a json storage and some jsoneditor as I already done in some other projects in the past. This could permits the backend user to generate all the desidered, specialized, field, per every user: storing key name and value.

Take a look here and let me know could be good for your approach https://github.com/peppelinux/django-freeradius/blob/master/django_freeradius/base/admin.py#L65

[daverickdunn]

@peppelinux This is awesome. It's exactly what I had in mind! If you like, I'm happy to fork your repo and implement one or more of the other algorithms...

[peppelinux]

@daverickdunn yes We can move forward, you have all my support. If you'll implement the other hash functions I'll move to coding the things I wrote

[daverickdunn]

@peppelinux Cool, I'll take a look this weekend.

[daverickdunn]

@nemesisdesign sorry, I was a bit busy yesterday evening so only getting round to giving you a proper response now.

We will be authenticating both users and devices. We are also trying to unify a lot of older systems/tools to use a single user authentication mechanism for better accounting and security (by unify I generally mean re-write).

I'll try describe our general scenario without too much faff. I'm working for a small ISP that mostly uses radio, but also fiber delivery. We're not a mobile carrier. A picture speaks a thousand words and this one pretty much sums up what our infrastructure looks like:

We have a lot of equipment, from several vendors, and the only thing that's somewhat standardised in managing them is, of course, RADIUS.

Managing a wireless network is and isn't as simple as a fiber or pots based networks. We need several levels of support engineers to login to devices at every node in the network, with different levels of access based on device type, etc. We also need devices to be automatically configured based on several factors, i.e. data limit reached, etc.

We're building a network management system from scratch that covers everything from sales, support and accounting, to a customer portal for managing their own data packages (down the road). This may sound like a monolithic monster, but we are actually being as modular as possible, however the one part that we really want to have completely unified is our AAA.

We decided to go with Django to host our webservices API for the new system, and RADIUS we cannot avoid, so that's what has me looking at packages such as this.

We're going to have to build a non-trival system to manage our network, and we're trying to find the best basis to build that system upon. There's no out of the box solution to our needs (open-source at least), and in terms of Django + RADIUS, your package appears to be the only one that provides at least some sort of starting point.

I understand your goals a bit better now, and although they're not exactly aligned with ours, I think there is scope here to generalise parts the project to create a platform for building out more specialised systems.

Hope that helps, and looking forward to seeing where this package goes!

Rich.

[nemesifier]

@daverickdunn thank you very much for the nice explanation and image! :+1:

Helping you in doing what you are doing is one of the goals of OpenWISP 2, so I'd like to make sure we get this done in a way that works well for all of us.

Maybe you could discover more open source modules you can reuse within the OpenWISP and NetJSON ecosystems, if you have time I suggest you to take a look at this presentation: OpenWISP 2 @ OpenWRT Summit 2017 Slides with the embedded videos are also available.

These two ecosystems are not mature yet, but I'm having a lot of positive feedback about the idea so we just need more time, constructive criticism and new contributors to improve it. I'm sure more resources will be available to accelerate this process if we spread the word.