Right that's better because the clear text password may contain dollar signs and the recognition would fail. If we check for the presence of "cleartext$" we can be sure that's a cleartext password, strip that part and take only the password from the string.
Thanks for bringing this up, I updated the github issue: https://github.com/openwisp/django-freeradius/issues/115 F. On Tue, May 15, 2018 at 5:08 PM Marco Cappellacci < [email protected]> wrote: > I thought about it and the cleartext password should be written with > dollar sign too, like cleartext$<password> > > > Il giorno mar 15 mag 2018 alle ore 14:07 Rohith Asrk < > [email protected]> ha scritto: > >> Looks good Federico. Working on it. >> >> On Tue, May 15, 2018 at 5:30 PM, Marco Cappellacci < >> [email protected]> wrote: >> >>> I totally agree with your solution >>> >>> Thank you >>> >>> Marco >>> >>> Il giorno mar 15 mag 2018 alle ore 13:48 Federico Capoano < >>> [email protected]> ha scritto: >>> >>>> This is the hashers django currently supports: >>>> https://docs.djangoproject.com/en/2.0/topics/auth/passwords/#included-hashers >>>> >>>> The case Marco has I think is unsalted md5. >>>> >>>> We need to figure out what's the best way to do this. >>>> >>>> Django stores the passwords in a way that the hashing algorithm is >>>> automatically understood, for example: >>>> >>>> >>> u = User.objects.last() >>>> >>> u.password >>>> >>>> 'pbkdf2_sha256$100000$mCxeZktfubPL$DKcpEYXK8dwW7qfGhrJOz0dxxsUryHcWyGi+Pj9u404=' >>>> >>>> Which indicates the password is hashed using the >>>> algorithm pbkdf2_sha256, which according to the django docs, is >>>> "django.contrib.auth.hashers.PBKDF2PasswordHasher" >>>> >>>> This other value: >>>> >>>> sha1$bd921$0ede5c7ab710dbd0af60ca21nfa871a678184849 >>>> >>>> Is salted sha1 with no iterations, notice this string has only 3 blocks >>>> (the previous one had 4: algorithm, iterations, salt, and hash). >>>> >>>> Unsalted md5 therefore should be something like (please verify by doing >>>> your own tests): >>>> >>>> unsalted_md5$vRTDfhKNvXqofawrtJXNPA== >>>> >>>> If I sum all this information up, the first and simplest solution that >>>> comes into my mind is the following: >>>> >>>> - the column dedicated to the password is optional, if not supplied >>>> passwords will be generated automatically >>>> - if the password column is present we have the following cases: >>>> - passwords should be written as django expects them (eg: like >>>> one of the previous password hashes I provided above), that means we >>>> should >>>> find at least one dollar sign in them, this means the users will >>>> have work >>>> a bit more to generate a correct CSV, and we will do less work, >>>> which is ok >>>> for now because we don't want to spend too much time on this, but it >>>> also >>>> mean the password must be saved as is, without further hashing >>>> - if the password does not contain any dollar sign, the system >>>> will assume it's a cleartext password and the password will be >>>> hashed with >>>> the default django password hasher >>>> >>>> Either of the cases in which the password is present should not be >>>> complicated to implement, it's just a matter of calling the right user >>>> model methods. >>>> >>>> Create a test case for each of the previous points, but for the hashed >>>> password case it would be better to create 3 tests, one for pbkdf2_sha256, >>>> one for salted sha1 and one for unsalted md5. >>>> >>>> Before working on this, please read this page entirely: >>>> https://docs.djangoproject.com/en/2.0/topics/auth/passwords/ >>>> >>>> I created a github issue: >>>> https://github.com/openwisp/django-freeradius/issues/115 >>>> >>>> Fed >>>> >>> >> -- 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.
