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 <meh...@edgle.com> 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 <meh...@edgle.com> > *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. 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 <ubernost...@gmail.com> > *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 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 a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/Xlovt28QIDo/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/django-developers/CAL13Cg_%2BKMi2naSExPR0MVvBb0JnY%3DFV7A6goDHeaTWRoSpaJQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > 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/5b8983f4.1c69fb81.971e7.10d8%40mx.google.com > <https://groups.google.com/d/msgid/django-developers/5b8983f4.1c69fb81.971e7.10d8%40mx.google.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFzonYbyDZHoxQyMYZ_aJbNg771HRLAwdnqh-qQQRhfkKTA6BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
