Include length in password strength evaluation

Here's an attempt at this. The strength is increased by one point for every character above 12 as long as no character is repeated within the password more than once. I'm sure there are lots of different ways to decide what kind of repetition is acceptable, so use this as a starting point if it's not exactly what you were thinking.

This needs to be considered in D7 first.

Patch re-rolled for D7. Assuming this feature is still desirable, I've confirmed that the password strength does continue to increase after 12 characters as long as characters are not repeated more than twice in a row.

Not sure why the patch failed on the poll module... I've rerolled it anyway though with a change to prevent the strength from going above 100.

#6: user-454014.patch queued for re-testing.

White Fir Design sent the following to the security team:

We just did a quick test to see how various web software rates or
restrict the use of passwords likely to be used in a dictionary attack,
as we have recently seen a campaign that has been attempting this type
of exploit (the campaign was targeting a CMS other than Drupal). We used
a list of 25 common passwords from
http://splashdata.com/splashid/worst-passwords/index.htm in the testing.
We found that Drupal 7 rated 22 of the passwords, including the password
"password", as being Fair and 3 as being Good. These ratings seem
questionable. This was already brought up two years ago,
http://drupal.org/node/693996, so you may have decided this is
acceptable but we felt it worth bringing to your attention in case it
slipped through the cracks. Corroborating the previous issue report we
found that the passwords rated as Fair are rated Low in Drupal 6 and the
passwords rated as Good are rated as Medium in Drupal 6.

The only other software that we tested that provides password strength
measurement, WordPress, rated 23 of passwords as Weak and two as Medium.
Several others have minimum requirements for passwords that would have
excluded the use all of the passwords that Drupal 7 rated as Fair.

Here is a straight reroll for 8.x.

Repeating characters is also handled in #340043: Warn against repeating character classes in passwords. It might make sense to handle that separately as a penalty since it doesn't only hurt us after character 12.

I'd like to see the score grow exponentially rather than linearly to better reflect how much length helps but I don't think my brain is up to that this afternoon.

For reference here is what wordpress is currently doing for it's password checks.

Another approach that might prove useful for generally improving password checks is over at [#1497920], but I think adding good length scoring should be the top priority here.

Here is an updated version that drops the repeated letter check (note to self to work on that as a separate patch).

Also added is an exponential increase after 8 characters. The calculation isn't technically correct mainly designed to make the bar change in a way that smoothly reflects the added strength.

I've also included a small penalty for less than 8 characters, this is mainly to make a smooth increase as a user types in a longer password instead of having a big jump at the magic number 6 which happened previously.

Looks pretty good. I guess we need the sec team looking at this.

You can replace the last two if in the patch bystrength = Math.min(strength + increase, 100);.

Update with nod's simplification.

Needs issue summary, and can probably be backported to D7

patch for D7 coming soon

attached is the patch for D7

attached is the patch for D7

Don't change the version until this is committed please.

I didn't know how to upload the patch for D7 and queue it for testing. Patch #17 is for D7, patch #13 is for D8.

Updated issue summary.

Created issue summary.

Updated issue summary.

reroll for 8.x

Actually that's exactly the same as #13 and that already worked.

This should be either a task or bug ... but fixing this is certainly not a feature...

We need tests to prove that this works.

It's a JS-only feature. And we can't test JS in core yet. Or do you mean something else?

@nod_ how right you are setting back to rtbc as per #22

Hmm.... so I manually tested this...

Current head

lMqzYK0fMjgdifcdYeN4ylMJ8bIMnFpB9nindLiz has strength 87.5
Aaa11 has strength 52.5
Aaa11rw! has strength 100

With this patch

lMqzYK0fMjgdifcdYeN4ylMJ8bIMnFpB9nindLiz has strength 100
Aaa11 has strength 52.5
Aaa11rw! has strength 80

However for some reason the last password Aaa11rw! generated the following issue with the patch (not without)...

added related dicttionary checking issue

It is worth noting that I have added a patch to #1497290: Check for common words in password strength indicators that will address this issue too. Perhaps this can be closed as a duplicate?

Confirmed that this issue is now covered by #1497290: Check for common words in password strength indicators. Closing this as a duplicate.

No duplicate unless #1497290: Check for common words in password strength indicators is actually implemented, which remains to be seen.
Also, this one here applies to D 8.6 and may be backported, while the other one probably won't be there before D 8.8.
Back to "needs work".

Recommended minimum password length used to be 6 characters, is now 12 characters (since #2177769: User module should recommend longer password).
While this may be a slight improvement, it still doesn't tackle the following problems:

1. There's no reward for passwords longer than the minimum recommended (now 12 characters)
2. The function is discontinuous and only weakly monotonic. While a password length of 11 characters receives 35% penalty (no better than "fair"), adding a single character will elevate the password to 0% penalty, right into the "strong" bin.
3. At the same time any additional character beyond 12 characters will not make any difference, no matter whether 12 or 16 or 25 characters are used.
4. A rather short, therefore clearly not strong, but otherwise at least mediocre password of 9 characters receives a harsh penalty of 50%, putting it right into the "weak" bin, where it coexists with outright insecure passwords of 1 or 2 characters.

What we need instead is a linear strongly monotonic function that effectively conveys that there is no clear-cut "good" or "bad", but varying degrees of "better" or "worse."

Here's a quite a bit better function:

let strength = 0;
strength += (((password.length + 1) ^ .27) - 1) * 100;

A simple exponential function, adding 1 to the length to assign a positive value to a length of 1 character, and with an exponent of .27 in order to approximate 100 points for a length of 12 characters:

[edit: Instead of "before" and "now", please read "current" and "proposed"].

Note that even if correctly measured, entropy is not the same as password strength. Entropy may climb faster and faster, and additional entropy always does make a password stronger. In real life, however, the first bits of entropy are the most important ones, while once a fair level is reached, the necessity of adding more and more entropy decreases.

Also note that this obviously still is a pragmatic rather than a purely scientific approach. I posted some interesting reads including current scientific literature in #1824800-110: Require a (configurable) minimum password length for user accounts, but we're currently so far away from the ideal approach that we need to approximate it step by step. Which is absolutely acceptable, as all reviews are showing (almost) none of the major networks, websites, OS's or CMS's follow a state-of-the-art scientific approach. Finally, even science still has a long way to go to grasp all relevant real-life parameters of password strength in full.

More important than whether we're using advanced mathematics is the fact we're not good at measuring entropy to begin with. This mainly is because entropy highly dependent on frequently used words, combinations and replacements rather than a simply function of password length. Two random characters may have a higher entropy than a single, long word with 12 or 15 characters. That's out-of-scope here, though, and may be improved in #1497290: Check for common words in password strength indicators.

Patch might require some recalibration of penalties, strength bins and tests, but for the moment I wanted to focus on the central aspect.

This one might be another tidbit better:

    let strength = 20;
    strength += ((password.length ^ .2375) - 1) * 100;

Again, note that the patch might require some recalibration of penalties, strength bins ("strong" should probably be no less than 100/100, "good" might start at 90/100 points, "fair" at 75/100 points) and tests, but for the moment I wanted to focus on the central aspect.

We can also shift the curve a bit downwards, if 12 characters including all (questionable) LUDS features don't have to be at 100/100 points.

Looks like great improvement, but it needs some testing coverage

This 100% feels like it'll need a CR,

Also the summary hasn't been touched in probably 10+ years lets make sure that's good to go

Thanks!