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 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. 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/5b898211.1c69fb81.7f961.e22f%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
