On Tue, Oct 6, 2020 at 9:07 AM Florian Apolloner <f.apollo...@gmail.com> wrote: > So, I have been digging a little bit more and it seems there was a conscious > decision to not include an entropy check or character classes: > https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/toKKgGhaqewJ -- > But I have to admit that this is all I could find and I was rather surprised > when you brought up the topic. I certainly would also have expected stronger > validation by default (then again I tend to customize those settings very > early on usually) -- maybe some kind of entropy check (but it's hard to write > a good error message on those).
A lot of this comes down to the threat model. Once upon a time, people prioritized "someone randomly guesses my password" as a major threat model and built validation routines to try to defeat it, by requiring high-entropy passwords. But the problem with this is that we've learned from experience what the far more common threat model is: some site you used once gets hacked, someone cracks all the hashes dumped from its user table (if it even hashed...), and then they know that jane...@example.com/"Passw0rd!" is a valid credential set and go plug it into every other site they can think of (a credential stuffing attack). The solution to this is twofold: better storage server-side for those of us who run sites with user accounts (Django does well at that), and trying to stop people from using or re-using common passwords. Which is why password entropy checks have fallen out of favor: it's far more important to push people to *unique* passwords than it is to push them to *complex* passwords. And if we make them set up complex passwords, people will do things like write those passwords on little pieces of paper stuck to their desks, which isn't good. Same if we make them rotate their password every three months (fun trivia: that recommendation apparently originated in an estimate of how long it would take a group of hackers, presumably working in shifts, to manually try every eight-character string on an ancient Unix system). So modern recommendations mostly focus on avoiding the credential-stuffing vector. For example, NIST 800-63B[1], for example, is particularly instructive: > Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” > that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt > subscribers to use specific types of information (e.g., “What was the name of > your first pet?”) when choosing memorized secrets. > > When processing requests to establish and change memorized secrets, verifiers > SHALL compare the prospective secrets against a list that contains values > known to be commonly-used, expected, or compromised. For example, the list > MAY include, but is not limited to: > > Passwords obtained from previous breach corpuses. > Dictionary words. > Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). > Context-specific words, such as the name of the service, the username, and > derivatives thereof. > > If the chosen secret is found in the list, the CSP or verifier SHALL advise > the subscriber that they need to select a different secret, SHALL provide the > reason for rejection, and SHALL require the subscriber to choose a different > value. > > Verifiers SHOULD offer guidance to the subscriber, such as a > password-strength meter [Meters], to assist the user in choosing a strong > memorized secret. This is particularly important following the rejection of a > memorized secret on the above list as it discourages trivial modification of > listed (and likely very weak) memorized secrets [Blacklists]. > > Verifiers SHALL implement a rate-limiting mechanism that effectively limits > the number of failed authentication attempts that can be made on the > subscriber’s account as described in Section 5.2.2. > > Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures > of different character types or prohibiting consecutively repeated > characters) for memorized secrets. Verifiers SHOULD NOT require memorized > secrets to be changed arbitrarily (e.g., periodically). However, verifiers > SHALL force a change if there is evidence of compromise of the authenticator. > > Verifiers SHOULD permit claimants to use “paste” functionality when entering > a memorized secret. This facilitates the use of password managers, which are > widely used and in many cases increase the likelihood that users will choose > stronger memorized secrets. Appendix A of that document -- which I won't quote, you should all read it yourselves! -- is especially enlightening in explaining why these particular recommendations were chosen. So the repeated-character password can be rejected, and maybe if we don't reject that we could add a validator for it. But arbitrary "entropy"/"complexity" requirements should not be added to Django, in my opinion, for the reasons stated above and backed up by NIST. [1] https://pages.nist.gov/800-63-3/sp800-63b.html -- 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/CAL13Cg_Ckc%2BosGx2RN1Su50vS%2BrpobkRdq1ukp-jpE-QtKVNYg%40mail.gmail.com.
