Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Dawid Czeluśniak]

Tom,

I believe that I found the root cause of this issue. Let's take a closer 
look at force_bytes 
 
function from Django and to_bytes 
 
function from Werkzeug (just for comparison). There is one *fundamental* 
difference 
between these: force_bytes from Django fallbacks to string representation 
of the object whereas to_bytes from Werkzeug raises TypeError if it can't 
cast the value to bytes. That's why when calling make_password with object 
that can't be "easily" cast to bytes returns a generated hash:

In [1]: from django.contrib.auth.hashers import make_password

In [2]: make_password([1, 2, 3])
Out[2]: 
'pbkdf2_sha256$18$Y9azq0uVWSoh$E7O13LefzP1I4MylXfFYKDkgCnZen6tf+FAblnBYssQ='

whereas generate_password_hash from Werkzeug raises TypeError:

In [16]: from werkzeug.security import generate_password_hash

In [17]: generate_password_hash([1, 2, 3])
TypeError: Expected bytes

IMHO throwing an exception is a more reasonable approach.

Anyway, thank you for your help :)
Dawid

On Thursday, 12 March 2020 19:17:15 UTC+1, Tom Forbes wrote:
>
> In this context it means that you shouldn’t encrypt, hash or otherwise 
> manipulate the password before passing it into the method. 
>
> Django, many other packages and Python itself will accept objects that can 
> be coerced into a string (via __str__) rather than throw an exception. 
> We’re all consenting adults here - if you want to pass a non-string object 
> into “make_password” then that’s up to you.
>
> The question really is if this is a common enough mistake to warrant a 
> guard against strange input. I’d say no, however a small change to the 
> documentation might be in order.
>
> Tom
>
> On 12 Mar 2020, at 17:41, Dawid Czeluśniak  > wrote:
>
> Adam,
>
> If it's perfectly fine to pass almost any not-None object to make_password 
> function and it returns correctly generated hash then why does the 
> documentation say:
>
> make_password(password, salt=None, hasher='default')
>> Creates a hashed password in the format used by this application. It 
>> takes one mandatory argument: the password in *plain-text*.
>
>  
>
> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#django.contrib.auth.hashers.make_password
>
> What does "plain-text" mean there?
>
> Thanks,
> Dawid
>
>
>
> On Thursday, 12 March 2020 18:18:59 UTC+1, Adam Johnson wrote:
>>
>> User provided passwords are validated already: 
>> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#module-django.contrib.auth.password_validation
>>
>> When using set_password directly, you as the programmer are responsible 
>> for ensuring the value you use for password is valid. Normally this means 
>> calling the functions detailed in "Integrating validation" beforehand.
>>
>> -- 
>> Adam
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/bda75e4c-2dae-42ef-91f3-c3054031c800%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/634ed9a2-72bb-4870-8a4a-e360a926efea%40googlegroups.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Tom Forbes]

In this context it means that you shouldn’t encrypt, hash or otherwise 
manipulate the password before passing it into the method. 

Django, many other packages and Python itself will accept objects that can be 
coerced into a string (via __str__) rather than throw an exception. We’re all 
consenting adults here - if you want to pass a non-string object into 
“make_password” then that’s up to you.

The question really is if this is a common enough mistake to warrant a guard 
against strange input. I’d say no, however a small change to the documentation 
might be in order.

Tom

> On 12 Mar 2020, at 17:41, Dawid Czeluśniak  wrote:
> 
> Adam,
> 
> If it's perfectly fine to pass almost any not-None object to make_password 
> function and it returns correctly generated hash then why does the 
> documentation say:
> 
> make_password(password, salt=None, hasher='default')
> Creates a hashed password in the format used by this application. It takes 
> one mandatory argument: the password in plain-text.
>  
> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#django.contrib.auth.hashers.make_password
>  
> 
> 
> What does "plain-text" mean there?
> 
> Thanks,
> Dawid
> 
> 
> 
> On Thursday, 12 March 2020 18:18:59 UTC+1, Adam Johnson wrote:
> User provided passwords are validated already: 
> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#module-django.contrib.auth.password_validation
>  
> 
> 
> When using set_password directly, you as the programmer are responsible for 
> ensuring the value you use for password is valid. Normally this means calling 
> the functions detailed in "Integrating validation" beforehand.
> 
> -- 
> Adam
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/bda75e4c-2dae-42ef-91f3-c3054031c800%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0E23455A-7EED-4EE5-AA90-8763BA68E5D7%40tomforb.es.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Dawid Czeluśniak]

Adam,

If it's perfectly fine to pass almost any not-None object to make_password 
function and it returns correctly generated hash then why does the 
documentation say:

make_password(password, salt=None, hasher='default')
> Creates a hashed password in the format used by this application. It takes 
> one mandatory argument: the password in *plain-text*.

 
https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#django.contrib.auth.hashers.make_password

What does "plain-text" mean there?

Thanks,
Dawid



On Thursday, 12 March 2020 18:18:59 UTC+1, Adam Johnson wrote:
>
> User provided passwords are validated already: 
> https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#module-django.contrib.auth.password_validation
>
> When using set_password directly, you as the programmer are responsible 
> for ensuring the value you use for password is valid. Normally this means 
> calling the functions detailed in "Integrating validation" beforehand.
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bda75e4c-2dae-42ef-91f3-c3054031c800%40googlegroups.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Adam Johnson]

User provided passwords are validated already:
https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#module-django.contrib.auth.password_validation

When using set_password directly, you as the programmer are responsible for
ensuring the value you use for password is valid. Normally this means
calling the functions detailed in "Integrating validation" beforehand.

On Thu, 12 Mar 2020 at 15:55, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> I agree with Adam, but in this case it seems to pose a security risk in
> case of user mistake, as such, raising a ValueError would have protect
> against the mistake of passing empty passwords, unless you consider empty
> passwords a feature of course in which case please dismiss my email.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9Xx6DvMQMWVWMRYMhbK-8nXfyPrNU_5ljWd-YuXeXRmz3_pnYXT6axEYrDBfW4K1v5OGEshIR2SDAeZxpnDBSk6SMLe4oeiwcrDMnz7xah4%3D%40protonmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1dOh5wvYha%3D7vY%2Bub8ZvTScqdG-qxEbtntTBx8OALMgg%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Dawid Czeluśniak]

I think that the root question here is: should we allow users to create 
passwords from anything that is not str? Now seems like make_password 
function allows to do that (Django 3.0.4):

In [1]: make_password(True)
Out[1]: 
'pbkdf2_sha256$18$WXVqmAhNTScA$bAiYHSr2fs3LbccZ+mDOAqE0vhYCPUOTVtot+TDTgSU='

In [2]: make_password(False)
Out[2]: 
'pbkdf2_sha256$18$19XGmulpDIUE$XbaYmfcbwPvlekI5RltSbRRJnfqLS7mfigb88VveOBY='

In [3]: make_password(list)
Out[3]: 
'pbkdf2_sha256$18$RkRlYdoMjKhR$QpSMO7wPNo3TVCGZk0BR1zolUI69OE2PFB7N3DYfBE0='

In [4]: make_password(frozenset)
Out[4]: 
'pbkdf2_sha256$18$qY0D7n7Q36Tb$1BDA0JcC0uz9RTIepDvcviU5O23WL/Cs/O9NX25fy18='

In [5]: make_password([1, 2, 3, {"hello": "world"}])
Out[5]: 
'pbkdf2_sha256$18$B4rNXyIZDrzM$pbdM797yYZzWu04WUrcZXBNNUwojSXZREkrbprxeP0A='

Many projects are actually checking the if the password is a str throwing 
the TypeError if it's not. I don't quite understand why Django should be an 
exception in this case...

https://fossies.org/linux/openslides/openslides/users/views.py#l_189
https://github.com/golismero/openvas_lib/blob/master/openvas_lib/common.py#L232
https://github.com/firebase/firebase-admin-python/blob/master/firebase_admin/_auth_utils.py#L73


On Thursday, 12 March 2020 00:06:44 UTC+1, Dawid Czeluśniak wrote:
>
> Hi all,
>
> I've noticed that both set_password and check_password methods accept 
> values other than str as parameters. For example I'm able to set password 
> to boolean values:
>
> In [1]: u.set_password(True)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(True)
> Out[4]: True
>
> In [5]: u.check_password('True')
> Out[5]: True
>
> What is even weirder, I'm able to set password as Exception class:
>
> In [1]: u.set_password(Exception)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(repr(Exception))
> Out[4]: True
>
> and the User instance itself:
>
> In [1]: u.set_password(u)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(u)
> Out[4]: True
>
> In [5]: u.check_password(str(u))
> Out[5]: True
>
> IMHO this is not correct behaviour especially because Django documentation 
> implies that these methods accept strings.
>
> set_password(raw_password)
>> Sets the user’s password to the given *raw string*, taking care of the 
>> password hashing. Doesn’t save the User object.
>>
>> check_password(raw_password)
>> Returns True if the given *raw string* is the correct password for the 
>> user. (This takes care of the password hashing in making the comparison.)
>
>
> Please let me know if this is reproducible on your side.
>
> Dawid
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8fe07285-ab2d-4a1f-9121-e6a6cae491af%40googlegroups.com.

[ANNOUNCE] A new governance model has been adopted for the Django project

[James Bennett]

For several years, there have been efforts underway to change the way
the Django open-source software project is run. This eventually
produced a concrete proposal, which then went through discussion,
revision, and voting by the Django core team, Django Technical Board,
and Django Software Foundation Board, and has now been accepted.

There's a blog post up with a summary and link to the full new
governance document:

https://www.djangoproject.com/weblog/2020/mar/12/governance/

But if you want a super-short summary: up until now, there have been
around 50 "core" developers with full commit access and
decision-making power, and a Technical Board to act as a tie-breaker.
But this wasn't how the project actually worked -- most "core"
developers were inactive, and most decisions were made by consensus on
the django-developers mailing list or in the bug tracker. So we are
moving to a system that formally recognizes this, and officially
adopts a more open, consensus-based process that does away with the
special group of "core" developers. Since this is mostly just saying
officially that we'll do things the way they've been working, users of
Django probably will not notice any change :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9hvNNHLM3nZqVAtT3vRbjTFibuZt-%3DgbgARwhk%2B489uw%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

I agree with Adam, but in this case it seems to pose a security risk in case of 
user mistake, as such, raising a ValueError would have protect against the 
mistake of passing empty passwords, unless you consider empty passwords a 
feature of course in which case please dismiss my email.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9Xx6DvMQMWVWMRYMhbK-8nXfyPrNU_5ljWd-YuXeXRmz3_pnYXT6axEYrDBfW4K1v5OGEshIR2SDAeZxpnDBSk6SMLe4oeiwcrDMnz7xah4%3D%40protonmail.com.

Re: Review needed: Proposed behavior change in Field.contribute_to_class()

[Mariusz Felisiak]

+1 from me.

Best,
Mariusz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10b2c605-4f10-489a-a9ed-08e1c39e4c8c%40googlegroups.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Ethem Güner]

I reproduced this case. Used a random model from my project.

Dawid Czeluśniak , 12 Mar 2020 Per, 02:06
tarihinde şunu yazdı:

> Hi all,
>
> I've noticed that both set_password and check_password methods accept
> values other than str as parameters. For example I'm able to set password
> to boolean values:
>
> In [1]: u.set_password(True)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(True)
> Out[4]: True
>
> In [5]: u.check_password('True')
> Out[5]: True
>
> What is even weirder, I'm able to set password as Exception class:
>
> In [1]: u.set_password(Exception)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(repr(Exception))
> Out[4]: True
>
> and the User instance itself:
>
> In [1]: u.set_password(u)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(u)
> Out[4]: True
>
> In [5]: u.check_password(str(u))
> Out[5]: True
>
> IMHO this is not correct behaviour especially because Django documentation
> implies that these methods accept strings.
>
> set_password(raw_password)
>> Sets the user’s password to the given *raw string*, taking care of the
>> password hashing. Doesn’t save the User object.
>>
>> check_password(raw_password)
>> Returns True if the given *raw string* is the correct password for the
>> user. (This takes care of the password hashing in making the comparison.)
>
>
> Please let me know if this is reproducible on your side.
>
> Dawid
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0429a2cd-a16c-429f-98b5-938629073ca5%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMsyPm9efom10quyfPZDk-c3oSu_9YHrNn5sVH9yzBs-YvwqOQ%40mail.gmail.com.

Re: [Probably BUG] set_password and check_password accept values other than string as parameters

[Adam Johnson]

Hi Dawid,

Welcome to the django-developers mailing list!

This is pretty normal Pythonic behaviour. Inside these methods, Django
casts the given object to a string with str() (specifically, in
force_bytes). Most objects can be cast to a string, although I agree many
of them won't necessarily make sense as passwords.

This is because Python normally leans on "duck typing". Runtime type
checking is normally used sparingly since it removes flexibility. Static
type checkers are gaining some popularity but it remains to be seen how far
they will affect Django and its ecosystem. Even then, I'm not sure we'd be
able to enforce strings-only as the type signature here, as it wouldn't be
backward compatible.

Thanks,

Adam

On Wed, 11 Mar 2020 at 22:40, Dawid Czeluśniak 
wrote:

> Hi all,
>
> I've noticed that both set_password and check_password methods accept
> values other than str as parameters. For example I'm able to set password
> to boolean values:
>
> In [1]: u.set_password(True)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(True)
> Out[4]: True
>
> In [5]: u.check_password('True')
> Out[5]: True
>
> What is even weirder, I'm able to set password as Exception class:
>
> In [1]: u.set_password(Exception)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(repr(Exception))
> Out[4]: True
>
> and the User instance itself:
>
> In [1]: u.set_password(u)
>
> In [2]: u.save()
>
> In [3]: u.refresh_from_db()
>
> In [4]: u.check_password(u)
> Out[4]: True
>
> In [5]: u.check_password(str(u))
> Out[5]: True
>
> IMHO this is not correct behaviour especially because Django documentation
> implies that these methods accept strings.
>
> set_password(raw_password)
>> Sets the user’s password to the given *raw string*, taking care of the
>> password hashing. Doesn’t save the User object.
>>
>> check_password(raw_password)
>> Returns True if the given *raw string* is the correct password for the
>> user. (This takes care of the password hashing in making the comparison.)
>
>
> Please let me know if this is reproducible on your side.
>
> Dawid
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0429a2cd-a16c-429f-98b5-938629073ca5%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3VHBjeQBbbbWXcu5_h%3DAjOFvMefz%3DoJ-iKHSAZKrrKLQ%40mail.gmail.com.