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$DKcpEYXK8dwW7qfGhrJOz0dxxsUryH
>> cWyGi+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.

Reply via email to