Oddity found in password creation

[Hélène Charpentier]

Hi,

When you create or modify a user account, the password has to be min. 8 characters long, not only numbers, not too simple.

But is it normal that you can use 8 times the same character?

E.g.: "hhhhhhhh", "pppppppp" are not allowed as a password ; "iiiiiiii", "&&&&&&&&" are allowed...

Thank you and have a nice day!

[Florian Apolloner]

Seem to be expected behaviour (albeit somewhat suboptimal :D). The default validators are: https://github.com/django/django/blob/999cddd58d30469f3ee85278985313fdf528323d/django/conf/project_template/project_name/settings.py-tpl#L87-L100 and from the looks of it hhhhhhhh/pppppppp is in the list of common passwords, whereas iiiiiiii/&&&&&&&& is not.

[hcharpent...@gmail.com]

Oh I see...

Thank you!

[hcharpent...@gmail.com]

I don't know if my thanks were sent - I'm looking for a "solved" button somewhere

Anyway, thank you (again?)

On Tuesday, October 6, 2020 at 4:30:34 PM UTC+2 f.apo...@gmail.com wrote:

[Florian Apolloner]

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).

I just double checked and hhhhhhhh/pppppppp are indeed in the common password list. Funny that they seem to be a) common enough to be included there and b) commoner than let's say iiiiiiii.

Cheers,

Florian

[Adam Johnson]

I recommend using https://pypi.org/project/pwned-passwords-django/ , which checks against the pwned passwords database and thus all known breached passwords. It's like the common passwords validator on steriods, but you do have to get your user communication right to explain how you know their reused password was breached.

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0f381205-ba70-4b89-9f34-5a2c459ac5f5n%40googlegroups.com.

--

Adam

[James Bennett]

On Tue, Oct 6, 2020 at 9:07 AM Florian Apolloner <f.apo...@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
jan...@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

[Roger Gammans]

On Tue, 2020-10-06 at 23:26 -0700, James Bennett wrote:
> > Passwords obtained from previous breach corpuses.

There even appears to be a 3rd party validator for this.
Although it only checks for inclusion, not total number
breaches that password was included in, which might be
a useful indicator you find it feel too strict.

https://github.com/koslibpro/django-pwned-password/

--
Roger Gammans <rgam...@gammascience.co.uk>
Gamma Science Ltd. (GB Nr. 07356014 )