Re: New Password Validators

[James Bennett]

I'm agreeing with the other replies saying that if this is really needed,
it can be done as a third-party module.

As much as possible, I want to have Django avoid promoting outdated
security policies (and the fact that many places still use them doesn't
mean they're current; it means they haven't caught up to the published best
practices).

The numeric validator does make some sense because there are cases where
you want an all-numeric credential, and where it's not bad practice to do
that. So it can stay, but I wouldn't want to add validators that try to
enforce false "complexity".

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_2NJvttfavz0i5WMg9tQzWMOMu6gpY49EKZ1bp6hD91A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Password Validators

[Dan Davis]

Mehmet,

If you need such complexity validators, then they are easy to add as
package.  I think the reason why Django doesn't include more is that many
use Oauth2 or other corporate authentication to validate.
You can see how this is done in one case by looking at
https://github.com/mingchen/django-cas-ng, which I use in my corporate
environment.

You can see other examples at
https://python-social-auth.readthedocs.io/en/latest/configuration/django.html

In the modern world, do we really need the ModelBackend much?   I hope not.

On Fri, Aug 31, 2018 at 2:07 PM Mehmet Dogan  wrote:

> 2 points I forgot to mention:
>
>
>
>1. I think it would be interesting to look at what other web
>frameworks are doing, e.g., Ruby on Rails
>2. If what I offered is not added, I think it makes more sense to
>remove similar ones (e.g., NumericPasswordValidator) from Django to make it
>self consistent.
>
>
>
> Mehmet
>
>
>
> *From: *Mehmet Dogan 
> *Sent: *Friday, August 31, 2018 12:59 PM
> *To: *django-developers@googlegroups.com
> *Subject: *RE: New Password Validators
>
>
>
> Hey James,
>
>
>
> Thank you for the resources you provided. I really learned a lot. Here are
> a few points (references/details at the very bottom):
>
>
>
>1. *Blacklisting: *Seems to be most effective, I agree. However,
>Django does not seem to be up to date on this either. The list of 1000 most
>common password it uses seem to be taken from an URL which is not available
>anymore, and the page it redirects to is dated 2011! So the list is at
>least around 10 years old, and it does not catch all of top 25 words listed
>on Wikipedia. Samples of passwords it allows: qwertyuiop, 987654321,
>1234567890, abcdefgh
>
>
>
>1. *Are Complexity Requirements Deprecated?: *I checked changing my 
> password
>for 3 major tech companies: Gmail, Microsoft account, and for my Apple Id.
>Only Gmail did not require password complexity. So, most do require
>password complexity although they do have 2-factor authentication in place.
>Most Django deployments, more than 95% I assume, would not have 2-factor
>authentication, so password complexity is more needed.
>
>
>
>1. *Do Complexity Requirements Work?: *
>   1. *Research: *From the resources you linked, I read one article
>   (ref’ed below). Here are key findings:
>
> *  i.  *A
> complex 8-character password had entropy of 34.3 where as a basic
> 8-character one had 29.43 (calculated with the specific method mentioned in
> the article). Not a huge difference, however not too bad either, that is
> about *17%* gain.
>
>  ii.  188/972
> (=*20%*) of the basic-8 passwords was cracked (with the tool mentioned in
> the article), whereas this number is *0 (zero)* for the complex-8 group.
> A big difference there.
>
>iii.  About
> 15% of the basic group wrote down their passwords, either electronically or
> paper and pencil, where as this number is about 27% for the complex.
> Simpler passwords is the winner here, however one should not forget,
> written passwords are expected have their own protection (of some sort).
> Another thing to consider is that, if one is targeted individually, a
> written password might be a big vulnerability; however, for general
> account/password screenings this may not be as bad.
>
> All in all, I say, password complexity has benefits; although not as much
> as one would expect.
>
>1. *Complexity and Blacklisting Can Interoperate: *For the simple case
>   of “Password1!” mentioned below, the best method to tackle, I think, 
> would
>   be 1) remove the numbers and characters at the end 2) lowercase the 
> first
>   character 3) lookup in the black list. In other words, tackle the 
> thinking
>   pattern algorithmically, not by listing cases in a text file.
>   2. *Complexity support blacklisting:* Check this list of common
>   passwords, for example:
>   
> https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/500-worst-passwords.txt
>   (provided by the Author of the Django’s list of common passwords). Most
>   items there are either all lowercase or all numbers etc. By just 
> requiring
>   1 upper case character, one could know off 60% off them. Adding a 
> number,
>   and a symbol requirement would easily bring that up to 95%.. Sure, those
>   who are committed to not password protecting their accounts would find
>   something in the remaining 5% (as in the example of “Password1!”),
>   howerver, policies would be made for the mainstream, not for the 
> extremes.
>
>
>
> Bottom line; I think password complexity do have some benefits, and
> inclusion in Django would provide options, and save time to those who would
> like to use them. 

the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[程SN]

Hi everybody,

the information is not enough for my company in
django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I
custom User and Team model.

the auth User can be changed in the django settings by AUTH_USER_MODEL. But
the Group cannot.

Further, There are many group permissions problem presented when I use
django permissions.

Firstly, I cannot use django.contrib.auth.ModelBackend directly.

in django.contrib.auth.ModelBackend,  Django currently bind group
permissions with  django.contrib.auth.models.Group

def _get_group_permissions(self, user_obj):
user_groups_field = get_user_model()._meta.get_field('groups')
user_groups_query = 'group
__%s' % user_groups_field.related_query_name()
return Permission.objects.filter(**{user_groups_query: user_obj})

Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  Can
Djano support AUTH_GROUP_MODEL in the further release?

So I have to custom backend that extend django.contrib.auth.ModelBackend
and modify group to my team.

But I find the other problem  in my further developing.  The bad design
 limit the other app design.

Many app about django permission , only  support group permission based on
django.contrib.auth.models.Group, like django-guardian

It's too bad.  Please support AUTH_GROUP_MODEL

--
Regards,

damoncheng

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: New Password Validators

[Mehmet Dogan]

2 points I forgot to mention:

1) I think it would be interesting to look at what other web frameworks are 
doing, e.g., Ruby on Rails
2) If what I offered is not added, I think it makes more sense to remove 
similar ones (e.g., NumericPasswordValidator) from Django to make it self 
consistent. 

Mehmet

From: Mehmet Dogan
Sent: Friday, August 31, 2018 12:59 PM
To: django-developers@googlegroups.com
Subject: RE: New Password Validators

Hey James,

Thank you for the resources you provided. I really learned a lot. Here are a 
few points (references/details at the very bottom):

1) Blacklisting: Seems to be most effective, I agree. However, Django does not 
seem to be up to date on this either. The list of 1000 most common password it 
uses seem to be taken from an URL which is not available anymore, and the page 
it redirects to is dated 2011! So the list is at least around 10 years old, and 
it does not catch all of top 25 words listed on Wikipedia. Samples of passwords 
it allows: qwertyuiop, 987654321, 1234567890, abcdefgh

2) Are Complexity Requirements Deprecated?: I checked changing my password for 
3 major tech companies: Gmail, Microsoft account, and for my Apple Id. Only 
Gmail did not require password complexity. So, most do require password 
complexity although they do have 2-factor authentication in place. Most Django 
deployments, more than 95% I assume, would not have 2-factor authentication, so 
password complexity is more needed. 

3) Do Complexity Requirements Work?: 
a) Research: From the resources you linked, I read one article (ref’ed below). 
Here are key findings: 
i. A complex 8-character password had entropy of 34.3 where as a basic 
8-character one had 29.43 (calculated with the specific method mentioned in the 
article). Not a huge difference, however not too bad either, that is about 17% 
gain. 
ii. 188/972 (=20%) of the basic-8 passwords was cracked (with the tool 
mentioned in the article), whereas this number is 0 (zero) for the complex-8 
group. A big difference there. 
iii. About 15% of the basic group wrote down their passwords, either 
electronically or paper and pencil, where as this number is about 27% for the 
complex. Simpler passwords is the winner here, however one should not forget, 
written passwords are expected have their own protection (of some sort). 
Another thing to consider is that, if one is targeted individually, a written 
password might be a big vulnerability; however, for general account/password 
screenings this may not be as bad. 
All in all, I say, password complexity has benefits; although not as much as 
one would expect. 
b) Complexity and Blacklisting Can Interoperate: For the simple case of 
“Password1!” mentioned below, the best method to tackle, I think, would be 1) 
remove the numbers and characters at the end 2) lowercase the first character 
3) lookup in the black list. In other words, tackle the thinking pattern 
algorithmically, not by listing cases in a text file.  
c) Complexity support blacklisting: Check this list of common passwords, for 
example: 
https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/500-worst-passwords.txt
 (provided by the Author of the Django’s list of common passwords). Most items 
there are either all lowercase or all numbers etc. By just requiring 1 upper 
case character, one could know off 60% off them. Adding a number, and a symbol 
requirement would easily bring that up to 95%.. Sure, those who are committed 
to not password protecting their accounts would find something in the remaining 
5% (as in the example of “Password1!”), howerver, policies would be made for 
the mainstream, not for the extremes. 

Bottom line; I think password complexity do have some benefits, and inclusion 
in Django would provide options, and save time to those who would like to use 
them. Regards,

Mehmet





References/Details: 

1) URL referenced in Django for the list of 1000 most common passwords : 
https://xato.net/passwords/more-top-worst-passwords/ 
(location: django\contrib\auth\password_validation.py)
Wikipedia: https://en.wikipedia.org/wiki/List_of_the_most_common_passwords
2) G-Mail: Use at least 8 characters. Don’t use a password from another site, 
or something too obvious like your pet’s name.
Microsoft Account: Strong passwords contain at least 8 characters, do not 
include common words or names, and combine uppercase letters, lowercase 
letters, numbers, and symbols.
Apple Id: Your password must have: i) 8 or more characters ii) Upper & 
lowercase letters iii) At least one number
3) a) Article: Of Passwords and People: Measuring the Effect of 
Password-Composition Policies 
(https://www.archive.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf). I 
picked this article since its name suggested it is very related to our topic, 
and that CMU is a reputable university. 


From: James Bennett
Sent: Thursday, August 30, 2018 10:32 PM
To: django-developers@googlegroups.com
Subject: Re: 

RE: New Password Validators

[Mehmet Dogan]

Hey James,

Thank you for the resources you provided. I really learned a lot. Here are a 
few points (references/details at the very bottom):

1) Blacklisting: Seems to be most effective, I agree. However, Django does not 
seem to be up to date on this either. The list of 1000 most common password it 
uses seem to be taken from an URL which is not available anymore, and the page 
it redirects to is dated 2011! So the list is at least around 10 years old, and 
it does not catch all of top 25 words listed on Wikipedia. Samples of passwords 
it allows: qwertyuiop, 987654321, 1234567890, abcdefgh

2) Are Complexity Requirements Deprecated?: I checked changing my password for 
3 major tech companies: Gmail, Microsoft account, and for my Apple Id. Only 
Gmail did not require password complexity. So, most do require password 
complexity although they do have 2-factor authentication in place. Most Django 
deployments, more than 95% I assume, would not have 2-factor authentication, so 
password complexity is more needed. 

3) Do Complexity Requirements Work?: 
a) Research: From the resources you linked, I read one article (ref’ed below). 
Here are key findings: 
i. A complex 8-character password had entropy of 34.3 where as a basic 
8-character one had 29.43 (calculated with the specific method mentioned in the 
article). Not a huge difference, however not too bad either, that is about 17% 
gain. 
ii. 188/972 (=20%) of the basic-8 passwords was cracked (with the tool 
mentioned in the article), whereas this number is 0 (zero) for the complex-8 
group. A big difference there. 
iii. About 15% of the basic group wrote down their passwords, either 
electronically or paper and pencil, where as this number is about 27% for the 
complex. Simpler passwords is the winner here, however one should not forget, 
written passwords are expected have their own protection (of some sort). 
Another thing to consider is that, if one is targeted individually, a written 
password might be a big vulnerability; however, for general account/password 
screenings this may not be as bad. 
All in all, I say, password complexity has benefits; although not as much as 
one would expect. 

b) Complexity and Blacklisting Can Interoperate: For the simple case of 
“Password1!” mentioned below, the best method to tackle, I think, would be 1) 
remove the numbers and characters at the end 2) lowercase the first character 
3) lookup in the black list. In other words, tackle the thinking pattern 
algorithmically, not by listing cases in a text file.  

c) Complexity support blacklisting: Check this list of common passwords, for 
example: 
https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/500-worst-passwords.txt
 (provided by the Author of the Django’s list of common passwords). Most items 
there are either all lowercase or all numbers etc. By just requiring 1 upper 
case character, one could know off 60% off them. Adding a number, and a symbol 
requirement would easily bring that up to 95%.. Sure, those who are committed 
to not password protecting their accounts would find something in the remaining 
5% (as in the example of “Password1!”), howerver, policies would be made for 
the mainstream, not for the extremes. 

Bottom line; I think password complexity do have some benefits, and inclusion 
in Django would provide options, and save time to those who would like to use 
them. Regards,

Mehmet






References/Details: 

1) URL referenced in Django for the list of 1000 most common passwords : 
https://xato.net/passwords/more-top-worst-passwords/ 
(location: django\contrib\auth\password_validation.py)
Wikipedia: https://en.wikipedia.org/wiki/List_of_the_most_common_passwords

2) G-Mail: Use at least 8 characters. Don’t use a password from another site, 
or something too obvious like your pet’s name.
Microsoft Account: Strong passwords contain at least 8 characters, do not 
include common words or names, and combine uppercase letters, lowercase 
letters, numbers, and symbols.
Apple Id: Your password must have: i) 8 or more characters ii) Upper & 
lowercase letters iii) At least one number

3) a) Article: Of Passwords and People: Measuring the Effect of 
Password-Composition Policies 
(https://www.archive.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf). I 
picked this article since its name suggested it is very related to our topic, 
and that CMU is a reputable university. 


From: James Bennett
Sent: Thursday, August 30, 2018 10:32 PM
To: django-developers@googlegroups.com
Subject: Re: New Password Validators

This type of enforced "complexity" does not increase security, and relevant 
standards groups now recommend not trying to enforce these rules.

Quoting US NIST 800-63B, Appendix A:

> As noted above, composition rules are commonly used in an attempt to increase 
>the difficulty of guessing user-chosen passwords. Research has shown, however, 
>that users respond in very predictable ways to the requirements 

Re: New Password Validators

[Anand Mishra]

I agree with James and Adams, password validation rules depend on business and 
should not be forced by core onto developers

> On Aug 31, 2018, at 12:52 PM, Adam Johnson  wrote:
> 
> I agree with James, Django core shouldn't include these. If your organization 
> requires you to implement such practices despite their problems, add your own 
> password validators, and maybe distribute them in a third party package!
> 
> On Fri, 31 Aug 2018 at 06:32, James Bennett  > wrote:
> This type of enforced "complexity" does not increase security, and relevant 
> standards groups now recommend not trying to enforce these rules.
> 
> Quoting US NIST 800-63B, Appendix A:
> 
> > As noted above, composition rules are commonly used in an attempt to 
> > increase the difficulty of guessing user-chosen passwords. Research has 
> > shown, however, that users respond in very predictable ways to the 
> > requirements imposed by composition rules [Policies]. For example, a user 
> > that might have chosen “password” as their password would be relatively 
> > likely to choose “Password1” if required to include an uppercase letter and 
> > a number, or “Password1!” if a symbol is also required.
> 
> The NIST guidelines now say (800-63B §5.1.1.1):
> 
> > Memorized secrets SHALL be at least 8 characters in length if chosen by the 
> > subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL 
> > be at least 6 characters in length and MAY be entirely numeric. If the CSP 
> > or verifier disallows a chosen memorized secret based on its appearance on 
> > a blacklist of compromised values, the subscriber SHALL be required to 
> > choose a different memorized secret. No other complexity requirements for 
> > memorized secrets SHOULD be imposed.
> 
> I would be against adding validators to Django to try to enforce these 
> deprecated practices.
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAL13Cg_%2BKMi2naSExPR0MVvBb0JnY%3DFV7A6goDHeaTWRoSpaJQ%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3PLGC%2B_y6SUsA_yOAuZqzfRZiyqOVbpsq%3DNbex%2B-eNjg%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .


-- 
This message contains confidential information and is intended only for the 
individual named. If you are not the name addressee you should not 
disseminate, distribute or copy this e-mail. You cannot use or forward any 
attachments in the email. Please notify the sender immediately by e-mail if 
you have received this e-mail by mistake and delete this e-mail from your 
system. Analytics Vidhya Educon Private Limited, DLF Phase 2, Gurgaon, 
India, www.analyticsvidhya.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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Django bugfix release: 2.1.1

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2018/aug/31/bugfix-release/

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/127D72C0-2CE8-45C2-A7FD-8E9A50BC7DB8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: New Password Validators

[Adam Johnson]

I agree with James, Django core shouldn't include these. If your
organization requires you to implement such practices despite their
problems, add your own password validators, and maybe distribute them in a
third party package!

On Fri, 31 Aug 2018 at 06:32, James Bennett  wrote:

> This type of enforced "complexity" does not increase security, and
> relevant standards groups now recommend not trying to enforce these rules.
>
> Quoting US NIST 800-63B, Appendix A:
>
> > As noted above, composition rules are commonly used in an attempt to
> increase the difficulty of guessing user-chosen passwords. Research has
> shown, however, that users respond in very predictable ways to the
> requirements imposed by composition rules [Policies]. For example, a user
> that might have chosen “password” as their password would be relatively
> likely to choose “Password1” if required to include an uppercase letter and
> a number, or “Password1!” if a symbol is also required.
>
> The NIST guidelines now say (800-63B §5.1.1.1):
>
> > Memorized secrets SHALL be at least 8 characters in length if chosen by
> the subscriber. Memorized secrets chosen randomly by the CSP or verifier
> SHALL be at least 6 characters in length and MAY be entirely numeric. If
> the CSP or verifier disallows a chosen memorized secret based on its
> appearance on a blacklist of compromised values, the subscriber SHALL be
> required to choose a different memorized secret. No other complexity
> requirements for memorized secrets SHOULD be imposed.
>
> I would be against adding validators to Django to try to enforce these
> deprecated practices.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg_%2BKMi2naSExPR0MVvBb0JnY%3DFV7A6goDHeaTWRoSpaJQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3PLGC%2B_y6SUsA_yOAuZqzfRZiyqOVbpsq%3DNbex%2B-eNjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.