subject:"Re\: \[openwisp\] django\-freeradius"

Re: [openwisp] django-freeradius coova-chilli password problem

2020-03-17 Thread Federico Capoano

Yes, nochallenge, sorry, I forgot the actual name of the config option to 
use.
Glad you found it and thanks for sharing it here, it will be useful for 
future reference.

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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/c650f42c-d478-4cef-91b0-f24d8953eaf4%40googlegroups.com.

Re: [openwisp] django-freeradius coova-chilli password problem

2020-03-13 Thread Иван Сугробов

Thanks! "nochallenge" flag made my day.

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/1a7889de-7499-44dd-a1b9-5568bd5fe3cd%40googlegroups.com.

Re: [openwisp] django-freeradius coova-chilli password problem

2020-03-13 Thread Saimanoj Seshagiri

plz share the url link to login



*Thanks & Regards,*
*Saimanoj Seshagiri ツ*
*+919505955568*


*Linkedin:-https://www.linkedin.com/in/saimanojseshagiri/
*


On Wed, Mar 11, 2020 at 10:48 PM Federico Capoano <
federico.capo...@gmail.com> wrote:

> You have to configure coova-chilli to send cleartext password.
> The password is encrypted with the shared secret and if you want more
> security you can configure coova to use TLS.
>
> Federico
>
> On Wed, Mar 11, 2020 at 11:04 AM Иван Сугробов 
> wrote:
>
>> Hello Everyone,
>>
>> I have a problem with social auth using django-freeradius.
>> When my page redirects user to coova-chilli logon endpoint with username
>> and password(token, see docs) , Radius server receives password, but this
>> passwords does not match.
>> Password that i sent to coova-chilli not equal with password that radius
>> server received by rest module.
>> I'm stuck with this.
>> What i'm doing wrong?
>>
>> Thanks,
>> Ivan Sugrobov
>>
>> --
>> 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 openwisp+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/openwisp/8fbe1b92-b11c-4cbe-9200-d71f3429e8e7%40googlegroups.com
>> 
>> .
>>
> --
> 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 openwisp+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openwisp/CAERYH6WCuTv-FEo1ZpCQJg6n6FNa8uUJpnMeGuL6jJVF9Oj%2BPw%40mail.gmail.com
> 
> .
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/CAO%3DF%2BgO1%3DFrnCjFCZf8XdM9zSwzS9G04yHwHXarC60HCMGEPuA%40mail.gmail.com.

Re: [openwisp] django-freeradius coova-chilli password problem

2020-03-11 Thread Federico Capoano

You have to configure coova-chilli to send cleartext password.
The password is encrypted with the shared secret and if you want more
security you can configure coova to use TLS.

Federico

On Wed, Mar 11, 2020 at 11:04 AM Иван Сугробов 
wrote:

> Hello Everyone,
>
> I have a problem with social auth using django-freeradius.
> When my page redirects user to coova-chilli logon endpoint with username
> and password(token, see docs) , Radius server receives password, but this
> passwords does not match.
> Password that i sent to coova-chilli not equal with password that radius
> server received by rest module.
> I'm stuck with this.
> What i'm doing wrong?
>
> Thanks,
> Ivan Sugrobov
>
> --
> 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 openwisp+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openwisp/8fbe1b92-b11c-4cbe-9200-d71f3429e8e7%40googlegroups.com
> 
> .
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/CAERYH6WCuTv-FEo1ZpCQJg6n6FNa8uUJpnMeGuL6jJVF9Oj%2BPw%40mail.gmail.com.

Re: [openwisp] django-freeradius, migration problem

2019-07-14 Thread 'unracer' via OpenWISP

You nailed it. After 
1) deleting the line:
openwisp-utils[qa]>=0.2.1
from the requirements file and
2) installing openwisp-utils in this way:
 pip install -e 
git+git://github.com/openwisp/openwisp-utils#egg=openwisp-utils

I can happily run the migration. Thank you 2stacks! 

On Sunday, July 14, 2019 at 4:12:15 PM UTC+2, 2stacks wrote:
>
> I believe its an issue with the requirements file and openwisp utils.  
> When I was having the same issue I had to pull from the master branch of 
> openwisp-utils in my req file.
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/94272fd5-e6ef-4246-bb26-ac287cc0a613%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius, migration problem

2019-07-14 Thread A Stanley

Sorry for multiple posts but heres the Dockerfile Im using to build Django
Freeradius.

https://github.com/2stacks/freeradius-django/blob/master/compose/django/Dockerfile

Also the pull request for the official Docker image is pending.

https://github.com/openwisp/docker-openwisp/pull/44


On Sun, Jul 14, 2019, 10:19 AM A Stanley <2sta...@2stacks.net> wrote:

> Its this commit to master thats missing from the latest release on PyPi.
>
> https://github.com/openwisp/openwisp-utils/issues/25
>
> On Sun, Jul 14, 2019, 10:12 AM A Stanley <2sta...@2stacks.net> wrote:
>
>> I believe its an issue with the requirements file and openwisp utils.
>> When I was having the same issue I had to pull from the master branch of
>> openwisp-utils in my req file.
>>
>> On Sun, Jul 14, 2019, 9:24 AM 'unracer' via OpenWISP <
>> openwisp@googlegroups.com> wrote:
>>
>>> Hello all,
>>>
>>> After cloning django-freeradius and installing the requirements (with
>>> pip install -r requirements-test.txt), I'm trying to migrate but I fail
>>> quite miserably. Any idea?
>>>
>>> Thanks and best,
>>>
>>> unracer
>>>
>>>
>>> (radius-dev) unracer@openwisp201:~/radius-dev/src/django-freeradius/tests$
>>> ./manage.py migrate
>>> Traceback (most recent call last):
>>>   File "./manage.py", line 10, in 
>>> execute_from_command_line(sys.argv)
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
>>> line 381, in execute_from_c
>>> utility.execute()
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
>>> line 357, in execute
>>> django.setup()
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/__init__.py",
>>> line 24, in setup
>>> apps.populate(settings.INSTALLED_APPS)
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/apps/registry.py",
>>> line 122, in populate
>>> app_config.ready()
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/apps.py",
>>> line 24, in ready
>>> self.module.autodiscover()
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/__init__.py",
>>> line 26, in autodiscover
>>> autodiscover_modules('admin', register_to=site)
>>>   File
>>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/utils/module_loading.py",
>>> line 47, in autodiscover_module
>>> import_module('%s.%s' % (app_config.name, module_to_search))
>>>   File "/home/unracer/radius-dev/lib/python3.6/importlib/__init__.py",
>>> line 126, in import_module
>>> return _bootstrap._gcd_import(name[level:], package, level)
>>>   File "", line 994, in _gcd_import
>>>   File "", line 971, in _find_and_load
>>>   File "", line 955, in
>>> _find_and_load_unlocked
>>>   File "", line 665, in _load_unlocked
>>>   File "", line 678, in exec_module
>>>   File "", line 219, in
>>> _call_with_frames_removed
>>>   File
>>> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/admin.py",
>>> line 6, in 
>>> from .base.admin import (
>>>   File
>>> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/base/admin.py",
>>> line 9, in 
>>> from openwisp_utils.admin import ReadOnlyAdmin,
>>> TimeReadonlyAdminMixin
>>> ImportError: cannot import name 'ReadOnlyAdmin'
>>>
>>> --
>>> 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 openwisp+unsubscr...@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/openwisp/228b0865-3c39-4812-98e5-8cf067b31e2b%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/CAP6YPdromVAY7-wmgAV6itxaOhHpthy0qH8zx5K9cq9sFVcDwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius, migration problem

2019-07-14 Thread A Stanley

Its this commit to master thats missing from the latest release on PyPi.

https://github.com/openwisp/openwisp-utils/issues/25

On Sun, Jul 14, 2019, 10:12 AM A Stanley <2sta...@2stacks.net> wrote:

> I believe its an issue with the requirements file and openwisp utils.
> When I was having the same issue I had to pull from the master branch of
> openwisp-utils in my req file.
>
> On Sun, Jul 14, 2019, 9:24 AM 'unracer' via OpenWISP <
> openwisp@googlegroups.com> wrote:
>
>> Hello all,
>>
>> After cloning django-freeradius and installing the requirements (with pip
>> install -r requirements-test.txt), I'm trying to migrate but I fail quite
>> miserably. Any idea?
>>
>> Thanks and best,
>>
>> unracer
>>
>>
>> (radius-dev) unracer@openwisp201:~/radius-dev/src/django-freeradius/tests$
>> ./manage.py migrate
>> Traceback (most recent call last):
>>   File "./manage.py", line 10, in 
>> execute_from_command_line(sys.argv)
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
>> line 381, in execute_from_c
>> utility.execute()
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
>> line 357, in execute
>> django.setup()
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/__init__.py",
>> line 24, in setup
>> apps.populate(settings.INSTALLED_APPS)
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/apps/registry.py",
>> line 122, in populate
>> app_config.ready()
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/apps.py",
>> line 24, in ready
>> self.module.autodiscover()
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/__init__.py",
>> line 26, in autodiscover
>> autodiscover_modules('admin', register_to=site)
>>   File
>> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/utils/module_loading.py",
>> line 47, in autodiscover_module
>> import_module('%s.%s' % (app_config.name, module_to_search))
>>   File "/home/unracer/radius-dev/lib/python3.6/importlib/__init__.py",
>> line 126, in import_module
>> return _bootstrap._gcd_import(name[level:], package, level)
>>   File "", line 994, in _gcd_import
>>   File "", line 971, in _find_and_load
>>   File "", line 955, in
>> _find_and_load_unlocked
>>   File "", line 665, in _load_unlocked
>>   File "", line 678, in exec_module
>>   File "", line 219, in
>> _call_with_frames_removed
>>   File
>> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/admin.py",
>> line 6, in 
>> from .base.admin import (
>>   File
>> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/base/admin.py",
>> line 9, in 
>> from openwisp_utils.admin import ReadOnlyAdmin, TimeReadonlyAdminMixin
>> ImportError: cannot import name 'ReadOnlyAdmin'
>>
>> --
>> 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 openwisp+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/openwisp/228b0865-3c39-4812-98e5-8cf067b31e2b%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/CAP6YPdqtwNUxhHjGLHiKjX63cJyF6uv4b0Kt%2BJXmiSAv1weChA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius, migration problem

2019-07-14 Thread A Stanley

I believe its an issue with the requirements file and openwisp utils.  When
I was having the same issue I had to pull from the master branch of
openwisp-utils in my req file.

On Sun, Jul 14, 2019, 9:24 AM 'unracer' via OpenWISP <
openwisp@googlegroups.com> wrote:

> Hello all,
>
> After cloning django-freeradius and installing the requirements (with pip
> install -r requirements-test.txt), I'm trying to migrate but I fail quite
> miserably. Any idea?
>
> Thanks and best,
>
> unracer
>
>
> (radius-dev) unracer@openwisp201:~/radius-dev/src/django-freeradius/tests$
> ./manage.py migrate
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
> line 381, in execute_from_c
> utility.execute()
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/core/management/__init__.py",
> line 357, in execute
> django.setup()
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/__init__.py",
> line 24, in setup
> apps.populate(settings.INSTALLED_APPS)
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/apps/registry.py",
> line 122, in populate
> app_config.ready()
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/apps.py",
> line 24, in ready
> self.module.autodiscover()
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/contrib/admin/__init__.py",
> line 26, in autodiscover
> autodiscover_modules('admin', register_to=site)
>   File
> "/home/unracer/radius-dev/lib/python3.6/site-packages/django/utils/module_loading.py",
> line 47, in autodiscover_module
> import_module('%s.%s' % (app_config.name, module_to_search))
>   File "/home/unracer/radius-dev/lib/python3.6/importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 994, in _gcd_import
>   File "", line 971, in _find_and_load
>   File "", line 955, in
> _find_and_load_unlocked
>   File "", line 665, in _load_unlocked
>   File "", line 678, in exec_module
>   File "", line 219, in
> _call_with_frames_removed
>   File
> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/admin.py",
> line 6, in 
> from .base.admin import (
>   File
> "/home/unracer/radius-dev/src/django-freeradius/django_freeradius/base/admin.py",
> line 9, in 
> from openwisp_utils.admin import ReadOnlyAdmin, TimeReadonlyAdminMixin
> ImportError: cannot import name 'ReadOnlyAdmin'
>
> --
> 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 openwisp+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/openwisp/228b0865-3c39-4812-98e5-8cf067b31e2b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/CAP6YPdoJCXTUdsSVhRzyz802aFc3U8vMhr%3DpWD8nn9RoUK7y-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] Django-FreeRadius

2018-10-28 Thread Bino Oetomo


Dear Sir.

I Appreciate your response.

So, one way or theother ... with 'CHAP' there will always a 'clear text 
password' stored some where.

I'm prettysure we can close this discussion.
I really appreciate your responses.

Sincerely
-bino-

On Saturday, October 27, 2018 at 10:55:44 PM UTC+7, Federico Capoano wrote:
>
> I correct myself, if I'm not wrong CHAP needs the password to be stored in 
> clear.
> The only way you can do that is to use radius checks, you can store the 
> clear password there.
>
> Users which have a corresponding django user will always have their 
> password hashed, it's one of the goal of django-freeradius to avoid storing 
> password in clear.
>
> Fed
>
>
>
>
>  

> I'm not sure how to implement that with the rml-rest module.
>>
>> There may be a way, if you find it please let me know, if we have a clear 
>> path on what we need to do to implement that we can open an issue on github 
>> and I think sooner or later we will find somebody else with the same need 
>> which may want to help implementing it.
>>
>> Fed
>>
>>
>> On Saturday, October 27, 2018 at 5:18:29 PM UTC+2, Bino Oetomo wrote:
>>>
>>>
>>>
>>> On Thursday, October 25, 2018 at 7:52:04 PM UTC+7, Federico Capoano 
>>> wrote:

 Passwords get to freeradius in clear over TLS (these are also encrypted 
 with the shared secret of freeradius BTW)


 I mean, if our Authenticator (i.e PPP gateway, Captive Portal, etc etc) 
>>> use a CHAP password, FreeRadius will not send ''User-Password' as part of 
>>> it's rlm_rest call to our rest-server. It'll send CHAP. That is I don't 
>>> know how to compare this to user's django password.
>>>
>>> Sincerely
>>> -bino-
>>>
>>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] Django-FreeRadius

2018-10-27 Thread Federico Capoano

I correct myself, if I'm not wrong CHAP needs the password to be stored in 
clear.
The only way you can do that is to use radius checks, you can store the 
clear password there.

Users which have a corresponding django user will always have their 
password hashed, it's one of the goal of django-freeradius to avoid storing 
password in clear.

Fed


On Saturday, October 27, 2018 at 5:53:44 PM UTC+2, Federico Capoano wrote:
>
> I'm not sure how to implement that with the rml-rest module.
>
> There may be a way, if you find it please let me know, if we have a clear 
> path on what we need to do to implement that we can open an issue on github 
> and I think sooner or later we will find somebody else with the same need 
> which may want to help implementing it.
>
> Fed
>
>
> On Saturday, October 27, 2018 at 5:18:29 PM UTC+2, Bino Oetomo wrote:
>>
>>
>>
>> On Thursday, October 25, 2018 at 7:52:04 PM UTC+7, Federico Capoano wrote:
>>>
>>> Passwords get to freeradius in clear over TLS (these are also encrypted 
>>> with the shared secret of freeradius BTW)
>>>
>>>
>>> I mean, if our Authenticator (i.e PPP gateway, Captive Portal, etc etc) 
>> use a CHAP password, FreeRadius will not send ''User-Password' as part of 
>> it's rlm_rest call to our rest-server. It'll send CHAP. That is I don't 
>> know how to compare this to user's django password.
>>
>> Sincerely
>> -bino-
>>
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] Django-FreeRadius

2018-10-27 Thread Federico Capoano

I'm not sure how to implement that with the rml-rest module.

There may be a way, if you find it please let me know, if we have a clear 
path on what we need to do to implement that we can open an issue on github 
and I think sooner or later we will find somebody else with the same need 
which may want to help implementing it.

Fed


On Saturday, October 27, 2018 at 5:18:29 PM UTC+2, Bino Oetomo wrote:
>
>
>
> On Thursday, October 25, 2018 at 7:52:04 PM UTC+7, Federico Capoano wrote:
>>
>> Passwords get to freeradius in clear over TLS (these are also encrypted 
>> with the shared secret of freeradius BTW)
>>
>>
>> I mean, if our Authenticator (i.e PPP gateway, Captive Portal, etc etc) 
> use a CHAP password, FreeRadius will not send ''User-Password' as part of 
> it's rlm_rest call to our rest-server. It'll send CHAP. That is I don't 
> know how to compare this to user's django password.
>
> Sincerely
> -bino-
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] Django-FreeRadius

2018-10-27 Thread Bino Oetomo



On Thursday, October 25, 2018 at 7:52:04 PM UTC+7, Federico Capoano wrote:
>
> Passwords get to freeradius in clear over TLS (these are also encrypted 
> with the shared secret of freeradius BTW)
>
>
> I mean, if our Authenticator (i.e PPP gateway, Captive Portal, etc etc) 
use a CHAP password, FreeRadius will not send ''User-Password' as part of 
it's rlm_rest call to our rest-server. It'll send CHAP. That is I don't 
know how to compare this to user's django password.

Sincerely
-bino-

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] Django-FreeRadius

2018-10-25 Thread Federico Capoano

On Thursday, October 25, 2018 at 11:58:22 AM UTC+2, Bino Oetomo wrote:
>
> Dear Federico sir.
>
> I really appreciate your very fast response.
>
> I think I misunderstood the docs.
>
> So, basically it's freeradius's requirement to all backend to provide 
> 'clear-text-password' right ?
>


Passwords get to freeradius in clear over TLS (these are also encrypted 
with the shared secret of freeradius BTW)

 

> If that so, 
> How you provide it since I don't see any 'clear text' field in your models?
> How you get 'clear text' password from django password storage ?
>
>
Passwords are stored in the user table with the default hashing algorithm 
used by django 
 and are 
checked via the django internal authentication API (eg: check_password()).

 

> Note : 
> Currently, since my app only support PAP ... i just use 
> django.contrib.auth.authenticate ... and whenever valid I just use that PAP 
> password as 'Clear-Text-Password' attribute.
> But if I want CHAP ... my App will not got clear-text-password from 
> Freeradius call ... we need to 'count' it. So I will not able to use 
> 'django.contrib.auth.authenticate' to authenticate user agains django user 
> table.
>
> Sincerely
> -bino-
>
> On Thursday, October 25, 2018 at 4:22:07 PM UTC+7, Federico Capoano wrote:
>>
>> Hi Bino and welcome,
>>
>> we use the rml-rest module of freeradius to authorize users via a REST 
>> API 
>> ,
>>  
>> although it is still possible to use radius checks as well as described 
>> here:
>>
>> https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#using-radius-checks-for-authorization-information
>>
>> If you need to see the freeradius configuration required to make this 
>> work, it's also shown in the same page I just linked.
>>
>> Cheers
>> Federico
>>
>> On Thu, Oct 25, 2018 at 11:00 AM Bino Oetomo  wrote:
>>
>>> Dear All.
>>>
>>> I just found your great django-freeradius today.
>>>
>>> Actualy, I wrote a django application with the same function as yours 
>>> back in october 2016.
>>> I guarantee there is a bunch of noodle script in it, away away from 
>>> 'good enough' to be published.
>>>
>>> Currently, those up is used in-house.
>>> it also serve as a backend for freeradius DHCP.
>>> it's full 'rest', so that freeradius didn't need mysql access.
>>>
>>> BUT ... errhhh
>>> I don't satisfied with my app (and or system).
>>> Most important things that I hate from it :It need to provide 
>>> 'Clear-Text-Password' to FreeRadius.
>>>
>>> Looks like your app don't need to give 'Clear-Text-Password' attribute 
>>> to FreeRadius, could you please tell me how you do it ?
>>>
>>> Here is my FreeRadius rest config :
>>>
>>> rest {
>>> #
>>> #  This subsection configures the tls related items
>>> #  that control how FreeRADIUS connects to a HTTPS
>>> #  server.
>>> #
>>> tls {
>>> }
>>>
>>> my_uri = "http://127.0.0.1:8000/hotspot/";
>>> my_uri_acct = "http://127.0.0.1:8001/hotspot/";
>>> authorize {
>>> uri = "${..my_uri}"
>>> method = 'post'
>>> body = 'json'
>>> tls = ${..tls}
>>> }
>>> authenticate {
>>> uri = "${..my_uri}"
>>> method = 'post'
>>> body = 'json'
>>> tls = ${..tls}
>>> }
>>> accounting {
>>> uri = "${..my_uri_acct}"
>>> method = 'post'
>>> body = 'json'
>>> tls = ${..tls}
>>> }
>>> post-auth {
>>> #uri = 
>>> "${..my_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?action=post-auth"
>>> uri = "${..my_uri}"
>>> method = 'post'
>>> body = 'json'
>>> tls = ${..tls}
>>> }
>>>
>>> pool {
>>> start = ${thread[pool].start_servers}
>>>
>>> min = ${thread[pool].min_spare_servers}
>>>
>>> max = ${thread[pool].max_servers}
>>>
>>> spare = ${thread[pool].max_spare_servers}
>>>
>>> uses = 0
>>>
>>> retry_delay = 30
>>>
>>> lifetime = 0
>>>
>>> idle_timeout = 60
>>>
>>> }
>>> }
>>>
>>>
>>>
>>>
>>>
>>> and here is some from default site config
>>>
>>> authorize {
>>> rest
>>> mschap
>>> pap
>>> eap
>>> }
>>> authenticate {
>>> pap
>>> mschap
>>> eap
>>> }
>>>
>>> preacct {
>>> preprocess
>>> acct_unique
>>> suffix
>>> files
>>> }
>>>
>>>
>>> accounting {
>>> rest
>>> detail
>>> exec
>>> }
>>>
>>> post-auth {
>>> update {
>>> &reply: += &session-state:
>>> }
>>> -sql
>>> exec
>>> remove_reply_message_if_eap
>>> Post-Auth-Type REJECT {
>>> # log failed authentications in SQL, too.
>>> -sql
>>> attr_filter.access_reject
>>>
>>> # Insert EAP-Failure message if the request was
>>> # rejected by policy instead of because of an
>>> # authentication failure
>>>

Re: [openwisp] Django-FreeRadius

2018-10-25 Thread Bino Oetomo

Dear Federico sir.

I really appreciate your very fast response.

I think I misunderstood the docs.

So, basically it's freeradius's requirement to all backend to provide 
'clear-text-password' right ?

If that so, 
How you provide it since I don't see any 'clear text' field in your models?
How you get 'clear text' password from django password storage ?

Note : 
Currently, since my app only support PAP ... i just use 
django.contrib.auth.authenticate ... and whenever valid I just use that PAP 
password as 'Clear-Text-Password' attribute.
But if I want CHAP ... my App will not got clear-text-password from 
Freeradius call ... we need to 'count' it. So I will not able to use 
'django.contrib.auth.authenticate' to authenticate user agains django user 
table.

Sincerely
-bino-

On Thursday, October 25, 2018 at 4:22:07 PM UTC+7, Federico Capoano wrote:
>
> Hi Bino and welcome,
>
> we use the rml-rest module of freeradius to authorize users via a REST API 
> ,
>  
> although it is still possible to use radius checks as well as described 
> here:
>
> https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#using-radius-checks-for-authorization-information
>
> If you need to see the freeradius configuration required to make this 
> work, it's also shown in the same page I just linked.
>
> Cheers
> Federico
>
> On Thu, Oct 25, 2018 at 11:00 AM Bino Oetomo  > wrote:
>
>> Dear All.
>>
>> I just found your great django-freeradius today.
>>
>> Actualy, I wrote a django application with the same function as yours 
>> back in october 2016.
>> I guarantee there is a bunch of noodle script in it, away away from 'good 
>> enough' to be published.
>>
>> Currently, those up is used in-house.
>> it also serve as a backend for freeradius DHCP.
>> it's full 'rest', so that freeradius didn't need mysql access.
>>
>> BUT ... errhhh
>> I don't satisfied with my app (and or system).
>> Most important things that I hate from it :It need to provide 
>> 'Clear-Text-Password' to FreeRadius.
>>
>> Looks like your app don't need to give 'Clear-Text-Password' attribute to 
>> FreeRadius, could you please tell me how you do it ?
>>
>> Here is my FreeRadius rest config :
>>
>> rest {
>> #
>> #  This subsection configures the tls related items
>> #  that control how FreeRADIUS connects to a HTTPS
>> #  server.
>> #
>> tls {
>> }
>>
>> my_uri = "http://127.0.0.1:8000/hotspot/";
>> my_uri_acct = "http://127.0.0.1:8001/hotspot/";
>> authorize {
>> uri = "${..my_uri}"
>> method = 'post'
>> body = 'json'
>> tls = ${..tls}
>> }
>> authenticate {
>> uri = "${..my_uri}"
>> method = 'post'
>> body = 'json'
>> tls = ${..tls}
>> }
>> accounting {
>> uri = "${..my_uri_acct}"
>> method = 'post'
>> body = 'json'
>> tls = ${..tls}
>> }
>> post-auth {
>> #uri = 
>> "${..my_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?action=post-auth"
>> uri = "${..my_uri}"
>> method = 'post'
>> body = 'json'
>> tls = ${..tls}
>> }
>>
>> pool {
>> start = ${thread[pool].start_servers}
>>
>> min = ${thread[pool].min_spare_servers}
>>
>> max = ${thread[pool].max_servers}
>>
>> spare = ${thread[pool].max_spare_servers}
>>
>> uses = 0
>>
>> retry_delay = 30
>>
>> lifetime = 0
>>
>> idle_timeout = 60
>>
>> }
>> }
>>
>>
>>
>>
>>
>> and here is some from default site config
>>
>> authorize {
>> rest
>> mschap
>> pap
>> eap
>> }
>> authenticate {
>> pap
>> mschap
>> eap
>> }
>>
>> preacct {
>> preprocess
>> acct_unique
>> suffix
>> files
>> }
>>
>>
>> accounting {
>> rest
>> detail
>> exec
>> }
>>
>> post-auth {
>> update {
>> &reply: += &session-state:
>> }
>> -sql
>> exec
>> remove_reply_message_if_eap
>> Post-Auth-Type REJECT {
>> # log failed authentications in SQL, too.
>> -sql
>> attr_filter.access_reject
>>
>> # Insert EAP-Failure message if the request was
>> # rejected by policy instead of because of an
>> # authentication failure
>> eap
>>
>> #  Remove reply message if the response contains an EAP-Message
>> remove_reply_message_if_eap
>> }
>> }
>>
>>
>>
>> Sincerely
>> -bino-
>>
>> -- 
>> 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 openwisp+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [openwisp] Django-FreeRadius

2018-10-25 Thread Federico Capoano

Hi Bino and welcome,

we use the rml-rest module of freeradius to authorize users via a REST API
,
although it is still possible to use radius checks as well as described
here:
https://django-freeradius.readthedocs.io/en/latest/general/freeradius.html#using-radius-checks-for-authorization-information

If you need to see the freeradius configuration required to make this work,
it's also shown in the same page I just linked.

Cheers
Federico

On Thu, Oct 25, 2018 at 11:00 AM Bino Oetomo  wrote:

> Dear All.
>
> I just found your great django-freeradius today.
>
> Actualy, I wrote a django application with the same function as yours back
> in october 2016.
> I guarantee there is a bunch of noodle script in it, away away from 'good
> enough' to be published.
>
> Currently, those up is used in-house.
> it also serve as a backend for freeradius DHCP.
> it's full 'rest', so that freeradius didn't need mysql access.
>
> BUT ... errhhh
> I don't satisfied with my app (and or system).
> Most important things that I hate from it :It need to provide
> 'Clear-Text-Password' to FreeRadius.
>
> Looks like your app don't need to give 'Clear-Text-Password' attribute to
> FreeRadius, could you please tell me how you do it ?
>
> Here is my FreeRadius rest config :
>
> rest {
> #
> #  This subsection configures the tls related items
> #  that control how FreeRADIUS connects to a HTTPS
> #  server.
> #
> tls {
> }
>
> my_uri = "http://127.0.0.1:8000/hotspot/";
> my_uri_acct = "http://127.0.0.1:8001/hotspot/";
> authorize {
> uri = "${..my_uri}"
> method = 'post'
> body = 'json'
> tls = ${..tls}
> }
> authenticate {
> uri = "${..my_uri}"
> method = 'post'
> body = 'json'
> tls = ${..tls}
> }
> accounting {
> uri = "${..my_uri_acct}"
> method = 'post'
> body = 'json'
> tls = ${..tls}
> }
> post-auth {
> #uri =
> "${..my_uri}/user/%{User-Name}/mac/%{Called-Station-ID}?action=post-auth"
> uri = "${..my_uri}"
> method = 'post'
> body = 'json'
> tls = ${..tls}
> }
>
> pool {
> start = ${thread[pool].start_servers}
>
> min = ${thread[pool].min_spare_servers}
>
> max = ${thread[pool].max_servers}
>
> spare = ${thread[pool].max_spare_servers}
>
> uses = 0
>
> retry_delay = 30
>
> lifetime = 0
>
> idle_timeout = 60
>
> }
> }
>
>
>
>
>
> and here is some from default site config
>
> authorize {
> rest
> mschap
> pap
> eap
> }
> authenticate {
> pap
> mschap
> eap
> }
>
> preacct {
> preprocess
> acct_unique
> suffix
> files
> }
>
>
> accounting {
> rest
> detail
> exec
> }
>
> post-auth {
> update {
> &reply: += &session-state:
> }
> -sql
> exec
> remove_reply_message_if_eap
> Post-Auth-Type REJECT {
> # log failed authentications in SQL, too.
> -sql
> attr_filter.access_reject
>
> # Insert EAP-Failure message if the request was
> # rejected by policy instead of because of an
> # authentication failure
> eap
>
> #  Remove reply message if the response contains an EAP-Message
> remove_reply_message_if_eap
> }
> }
>
>
>
> Sincerely
> -bino-
>
> --
> 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 openwisp+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius

2017-10-23 Thread Alessia Ventani

I started this work this morning and I haven't finished the installation
yet. In the next days I will do all these things. Thank you for your
advices!

Alessia

2017-10-23 15:17 GMT+02:00 Federico Capoano :

> Hi Alessia and welcome,
>
> glad to have a new contributor on-board!
>
> I suggest you to start with the following steps:
>
>- start and fork the repo on github (noticed you forked but did not
>star)
>- perform a development install following the docs
>- build the docs offline
>- if you find anything that can be improved in the docs, please do so
>and send a pull request
>- remember it's better to send 1 pull request (creating one branch for
>each) for each group of change (eg: 1 PR for improving docs, 1 PR for
>fixing a bug, and so on)
>- one easy issue you can start working on is the following:
>https://github.com/openwisp/django-freeradius/issues/43
>
>- I also suggest you to join us at https://gitter.im/openwisp/general
>
> That would be a good start :-)
>
> Federico
>
> On Mon, Oct 23, 2017 at 12:54 PM Alessia Ventani 
> wrote:
>
>> hi folks,
>> I'm Alessia, I just started to work on this project.
>> I'm a student of the University of Urbino and I work with Marco. I'm very
>> happy to help!!
>> If anyone has any suggestion, just write to me!
>>
>> Bye Alessia
>>
>> --
>> 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 openwisp+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenWISP" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/openwisp/A2r91Vrti3k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> openwisp+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius

2017-10-23 Thread Federico Capoano

Hi Alessia and welcome,

glad to have a new contributor on-board!

I suggest you to start with the following steps:

   - start and fork the repo on github (noticed you forked but did not star)
   - perform a development install following the docs
   - build the docs offline
   - if you find anything that can be improved in the docs, please do so
   and send a pull request
   - remember it's better to send 1 pull request (creating one branch for
   each) for each group of change (eg: 1 PR for improving docs, 1 PR for
   fixing a bug, and so on)
   - one easy issue you can start working on is the following:
   https://github.com/openwisp/django-freeradius/issues/43
   - I also suggest you to join us at https://gitter.im/openwisp/general

That would be a good start :-)

Federico

On Mon, Oct 23, 2017 at 12:54 PM Alessia Ventani 
wrote:

> hi folks,
> I'm Alessia, I just started to work on this project.
> I'm a student of the University of Urbino and I work with Marco. I'm very
> happy to help!!
> If anyone has any suggestion, just write to me!
>
> Bye Alessia
>
> --
> 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 openwisp+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-15 Thread Leonardo Maccari


> Ok I understand you don't want to have MD5/SHA1, but with the PAP
> solution, you don't have to. Unless you are telling me that the
> documentation or rlm_pap is wrong:
>
> https://freeradius.org/radiusd/man/rlm_pap.txt
>
> which is entirely plausible. Even if I am thinking that i miss
> some pieces because i don't understand why you want to replicate
> the user DB, once you have a RADIUS server. 
>
>
> I don't think the documentation is wrong.
>
> See the following table in that documentation:
> Header   Attribute   Description
> --   -   ---
> {clear}  Cleartext-Password  clear-text passwords
> {cleartext}  Cleartext-Password  clear-text passwords
> {crypt}  Crypt-Password  Unix-style "crypt"ed passwords
> {md5}MD5-PasswordMD5 hashed passwords
> {base64_md5} MD5-PasswordMD5 hashed passwords
> {smd5}   SMD5-Password   MD5 hashed passwords, with a salt
> {sha}SHA-PasswordSHA1 hashed passwords
>  SHA1-Password   SHA1 hashed passwords
> {ssha}   SSHA-Password   SHA1 hashed passwords, with a 
> salt
>  SSHA1-Password  SHA1 hashed passwords, with a 
> salt
> {ssh2}   SHA2-Password   SHA2 hashed passwords
> {ssh256} SHA2-Password   SHA2 hashed passwords
> {ssh512} SHA2-Password   SHA2 hashed passwords
> {nt} NT-Password Windows NT hashed passwords
> {nthash} NT-Password Windows NT hashed passwords
> {x-nthash}   NT-Password Windows NT hashed passwords
> {ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords
> {x- orcllmv} LM-Password Windows LANMAN hashed passwords
> {X- orclntv} LM-Password Windows LANMAN hashed passwords
> When receiving a password with the PAP module, we have to choose
> either one of those algorithms or cleartext. Se we are choosing
> cleartext (over an encrypted tunnel if necessary), but delegating the
> authorization, that is the check of the password stored with a
> stronger hashing algorithm (and possibly more complex checks) to an
> external application.

Exactly, my point is I have read that you can convince LDAP to do that,
without doing it yourself. What is not entirely clear to me is if you
can actually convince the module to do it for you, with one of the more
secure hashes in the list and then use any other DB.

> let's try again: what is the architecture you have in mind? given
> the following scheme:
>
>
> SU --- AU  -- Radius  DB
>
> what are the components you control and what are the external
> components you only plan to connect to?
>
>  
> In public wifi or university wifi settings, we control everything.
> captive portal, VPNs, freeradius, openwisp2.
>
> In other settings like Eduroam or other 802.1x settings we may not
> have control of access points that talk to freeradius, in that case we
> would need to properly setup the TTLS tunnel between freeradius and
> the parts we don't control.
>
> Let me offer a bit more context about django-freeradius
>  because maybe you are
> not aware of it. We are working to renovate an existing application
> called OpenWISP User Management System
> , which
> is basically a freeradius management interface which creates a (very
> weird) MySQL database that is then used by freeradius (usually
> deployed with freeradius 2). This application has been used for many
> years by many companies and municipalities to offer public wifi. OWUMS
> has many important limitations and shortcomings which we are trying to
> solve with this renovation.
> So with django-freeradius we are trying to create the base openwisp2
> module that will take care of AAA in openwisp2, but in a cleaner way
> which we aim will be simpler to extend and less costly to mantain and
> evolve over time.
>
> I hope is clearer now.

Thank you Federico, now everything is clear and I also understand your
solution.

best,
leonardo.

>
> 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 openwisp+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Leonardo Maccari, Assistant Professor @DISI, University of Trento
Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7

-- 
You received this message because you are subscribed to the Google Groups 
"OpenWISP" group.
To unsubscribe from this gro

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-14 Thread Federico Capoano

On Fri, Jul 14, 2017 at 11:53 AM Leonardo Maccari 
wrote:

>
> On 14/07/17 10:43, Federico Capoano wrote:
>
>
>
> On Thu, Jul 13, 2017 at 11:00 PM Leonardo Maccari <
> leonardo.macc...@unitn.it> wrote:
>
>>
>>
>> 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.
>>
>>
>> maybe I was not clear enough, need a picture to explain:
>>
>>  SU --- AU  -- Radius  DB
>>
>> this is the typical authentiation set-up, with a supplicant, an
>> authenticator, a radius and a user db. I think in your case SU and AU are
>> co-located in the web server.
>>
>> With protocols like MSCHAPv2 this happens:
>>
>>
>>  SU --- AU  -- Radius  DB
>> hash(pwd)-->
>>
>> so basically Radius knows nothing about hashes, and you have to cope with
>> crappy hashes (which, BTW, is what everybody uses, because you still pass
>> through a TLS tunnel, so it is not that horrible, and collisions are still
>> hard enough not to be practical).
>>
>> With PAP this happens:
>>
>>  SU --- AU  -- Radius  DB
>> pwd-->hash(pwd)
>>
>> So the pwd passes in the clear up to the DB. There you can hash it with
>> whatever you want, including a salted SHA256. But, since everything passes
>> in clear, you have to be extremely sure that you have no leaks anywhere
>> (and that authentication is bi-directional in some way, but this may not be
>> your case).  I am pretty sure there is a working ldap configuration for
>> this, even if i never tried it myself.
>>
>
> Yes this is the solutions we are talking about, using PAP (encrypted with
> TTLS or not depending on where the communication between radius clients and
> radius).
>
> Each method has trade offs. The method we have discussed is easy enough to
> implement, secure, flexible, has low mantainance costs.
>
> As said, storing passwords in SHA1 or MD5 is not viable unless we only
> store passwords in that form only for users of a freeradius
> instance/federation, but we would need to store these passwords in a
> different location than the main user passwords (eg: administrators,
> operators, future contributors when we will introduce the possibility of
> contributing to the network by adding nodes into the system), this means we
> should keep the SHA1/MD5 encrypted passwords for freeradius users either in
> separate fields or a different DB entirely: this solution would be
> cumbersome, bug prone and costly to mantain.
>
>
> Ok I understand you don't want to have MD5/SHA1, but with the PAP
> solution, you don't have to. Unless you are telling me that the
> documentation or rlm_pap is wrong:
>
> https://freeradius.org/radiusd/man/rlm_pap.txt
>
which is entirely plausible. Even if I am thinking that i miss some pieces
> because i don't understand why you want to replicate the user DB, once you
> have a RADIUS server.
>

I don't think the documentation is wrong.

See the following table in that documentation:

  Header   Attribute   Description
  --   -   ---
  {clear}  Cleartext-Password  clear-text passwords
  {cleartext}  Cleartext-Password  clear-text passwords
  {crypt}  Crypt-Password  Unix-style "crypt"ed passwords
  {md5}MD5-PasswordMD5 hashed passwords
  {base64_md5} MD5-PasswordMD5 hashed passwords
  {smd5}   SMD5-Password   MD5 hashed passwords, with a salt
  {sha}SHA-PasswordSHA1 hashed passwords
   SHA1-Password   SHA1 hashed passwords
  {ssha}   SSHA-Password   SHA1 hashed passwords, with a 
salt
   SSHA1-Password  SHA1 hashed passwords, with a 
salt
  {ssh2}   SHA2-Password   SHA2 hashed passwords
  {ssh256} SHA2-Password   SHA2 hashed pass

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-14 Thread Leonardo Maccari


On 14/07/17 10:43, Federico Capoano wrote:
>
>
> On Thu, Jul 13, 2017 at 11:00 PM Leonardo Maccari
> mailto:leonardo.macc...@unitn.it>> wrote:
>
>
>>
>> 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.
>
> maybe I was not clear enough, need a picture to explain:
>
>  SU --- AU  -- Radius  DB
>
> this is the typical authentiation set-up, with a supplicant, an
> authenticator, a radius and a user db. I think in your case SU and
> AU are co-located in the web server.
>
> With protocols like MSCHAPv2 this happens:
>
>
>  SU --- AU  -- Radius  DB
> hash(pwd)-->
>
> so basically Radius knows nothing about hashes, and you have to
> cope with crappy hashes (which, BTW, is what everybody uses,
> because you still pass through a TLS tunnel, so it is not that
> horrible, and collisions are still hard enough not to be practical).
>
> With PAP this happens:
>
>  SU --- AU  -- Radius  DB
> pwd-->hash(pwd)
>
> So the pwd passes in the clear up to the DB. There you can hash it
> with whatever you want, including a salted SHA256. But, since
> everything passes in clear, you have to be extremely sure that you
> have no leaks anywhere (and that authentication is bi-directional
> in some way, but this may not be your case).  I am pretty sure
> there is a working ldap configuration for this, even if i never
> tried it myself. 
>
>  
> Yes this is the solutions we are talking about, using PAP (encrypted
> with TTLS or not depending on where the communication between radius
> clients and radius).
>
> Each method has trade offs. The method we have discussed is easy
> enough to implement, secure, flexible, has low mantainance costs.
>
> As said, storing passwords in SHA1 or MD5 is not viable unless we only
> store passwords in that form only for users of a freeradius
> instance/federation, but we would need to store these passwords in a
> different location than the main user passwords (eg: administrators,
> operators, future contributors when we will introduce the possibility
> of contributing to the network by adding nodes into the system), this
> means we should keep the SHA1/MD5 encrypted passwords for freeradius
> users either in separate fields or a different DB entirely: this
> solution would be cumbersome, bug prone and costly to mantain.

Ok I understand you don't want to have MD5/SHA1, but with the PAP
solution, you don't have to. Unless you are telling me that the
documentation or rlm_pap is wrong:

https://freeradius.org/radiusd/man/rlm_pap.txt

which is entirely plausible. Even if I am thinking that i miss some
pieces because i don't understand why you want to replicate the user DB,
once you have a RADIUS server.

> before i answer, maybe i miss the big picture. generally you want
> to interface to RADIUS because you have some external DB of
> passwords that are already in use, and you want to plug your
> application into it. But maybe you are interested in the other way
> around, you want to embed an user DB and a FreeRadius server into
> the host where openwisp is running, so you can offer to
> third-party applications all-in-one with OpenWISP and a RADIUS
> interface?
>
>  
> Sorry, I'm not following you.

let's try again: what is the architecture you have in mind? given the
following scheme:

SU --- AU  -- Radius  DB

what are the components you control and what are the external components
you only plan to connect to?

l.

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

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-14 Thread Federico Capoano

On Thu, Jul 13, 2017 at 11:00 PM Leonardo Maccari 
wrote:

>
>
> 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.
>
>
> maybe I was not clear enough, need a picture to explain:
>
>  SU --- AU  -- Radius  DB
>
> this is the typical authentiation set-up, with a supplicant, an
> authenticator, a radius and a user db. I think in your case SU and AU are
> co-located in the web server.
>
> With protocols like MSCHAPv2 this happens:
>
>
>  SU --- AU  -- Radius  DB
> hash(pwd)-->
>
> so basically Radius knows nothing about hashes, and you have to cope with
> crappy hashes (which, BTW, is what everybody uses, because you still pass
> through a TLS tunnel, so it is not that horrible, and collisions are still
> hard enough not to be practical).
>
> With PAP this happens:
>
>  SU --- AU  -- Radius  DB
> pwd-->hash(pwd)
>
> So the pwd passes in the clear up to the DB. There you can hash it with
> whatever you want, including a salted SHA256. But, since everything passes
> in clear, you have to be extremely sure that you have no leaks anywhere
> (and that authentication is bi-directional in some way, but this may not be
> your case).  I am pretty sure there is a working ldap configuration for
> this, even if i never tried it myself.
>

Yes this is the solutions we are talking about, using PAP (encrypted with
TTLS or not depending on where the communication between radius clients and
radius).

Each method has trade offs. The method we have discussed is easy enough to
implement, secure, flexible, has low mantainance costs.

As said, storing passwords in SHA1 or MD5 is not viable unless we only
store passwords in that form only for users of a freeradius
instance/federation, but we would need to store these passwords in a
different location than the main user passwords (eg: administrators,
operators, future contributors when we will introduce the possibility of
contributing to the network by adding nodes into the system), this means we
should keep the SHA1/MD5 encrypted passwords for freeradius users either in
separate fields or a different DB entirely: this solution would be
cumbersome, bug prone and costly to mantain.


>
> 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.
>
>
> before i answer, maybe i miss the big picture. generally you want to
> interface to RADIUS because you have some external DB of passwords that are
> already in use, and you want to plug your application into it. But maybe
> you are interested in the other way around, you want to embed an user

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-13 Thread Leonardo Maccari


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

maybe I was not clear enough, need a picture to explain:

 SU --- AU  -- Radius  DB

this is the typical authentiation set-up, with a supplicant, an
authenticator, a radius and a user db. I think in your case SU and AU
are co-located in the web server.

With protocols like MSCHAPv2 this happens:


 SU --- AU  -- Radius  DB
hash(pwd)-->

so basically Radius knows nothing about hashes, and you have to cope
with crappy hashes (which, BTW, is what everybody uses, because you
still pass through a TLS tunnel, so it is not that horrible, and
collisions are still hard enough not to be practical).

With PAP this happens:

 SU --- AU  -- Radius  DB
pwd-->hash(pwd)

So the pwd passes in the clear up to the DB. There you can hash it with
whatever you want, including a salted SHA256. But, since everything
passes in clear, you have to be extremely sure that you have no leaks
anywhere (and that authentication is bi-directional in some way, but
this may not be your case).  I am pretty sure there is a working ldap
configuration for this, even if i never tried it myself.

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

before i answer, maybe i miss the big picture. generally you want to
interface to RADIUS because you have some external DB of passwords that
are already in use, and you want to plug your application into it. But
maybe you are interested in the other way around, you want to embed an
user DB and a FreeRadius server into the host where openwisp is running,
so you can offer to third-party applications all-in-one with OpenWISP
and a RADIUS interface?

best,
leonardo.



>
> 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 openwisp+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Leonardo Maccari, Assistant Professor @DISI, University of Trento
Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-13 Thread Federico Capoano

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  by 
> default and allows for even stronger algorithms, see the Password 
> Management  
> 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

Re: [openwisp] [django-freeradius] Hash algorithm issue

2017-07-12 Thread Leonardo Maccari


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

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.

>
> 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  by
> default and allows for even stronger algorithms, see the Password
> Management
> 
> 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.

best,
leonardo.

-- 
Leonardo Maccari, Assistant Professor @DISI, University of Trento
Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7

-- 
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 openwisp+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [openwisp] django-freeradius coova-chilli password problem

Re: [openwisp] django-freeradius coova-chilli password problem

Re: [openwisp] django-freeradius coova-chilli password problem

Re: [openwisp] django-freeradius coova-chilli password problem

Re: [openwisp] django-freeradius, migration problem

Re: [openwisp] django-freeradius, migration problem

Re: [openwisp] django-freeradius, migration problem

Re: [openwisp] django-freeradius, migration problem

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] Django-FreeRadius

Re: [openwisp] django-freeradius

Re: [openwisp] django-freeradius

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

Re: [openwisp] [django-freeradius] Hash algorithm issue

24 matches

Site Navigation

Mail list logo

Footer information