(In reply to comment #0)

Per discussion on en.wiki, the community decided to place a password strength
bar. This was 1 month ago. It wasn't implemented yet so I am requesting it
now.

If you want anything to happen, it has to be put into bugzilla after consensus has been reached.

Link to consensus is needed.

Also, this will require some time from our developers. If you have someone who can provide a PHP patch that will make this happen much more quickly.

ebe123_wiki wrote:

Here's the link: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Account_security#Improve_password_strength

Anyone intending to fix this should read through the comments on r70520 first.

Created attachment 9507
Incomplete work on a password strength checker

There's community consensus to implement on enwiki, but as Bawolff points out, there is an existing implementation at r70520 and no consensus as to whether to implement it or not.

I've attached what I've worked on so far, but as there isn't consensus on this, I don't see much point going forward on it.

Attached:

Some research is supporting this more, under certain circumstances:

https://research.microsoft.com/pubs/192108/chi13b.pdf

From the abstract, "We conclude that meters result in stronger passwords when users are forced to change existing passwords on “important” accounts and that individual meter design decisions likely have a marginal impact."

So if we assume that users of privileged accounts consider their wiki account "important," then this could improve the overall security of those accounts. For most users, their wiki account is probably something they consider unimportant, so the meter is probably useless for them.

Maybe we can only display the meter when someone with privileges sets their password?

This has been stuck in purgatory for a while now. How about we at least provide a Special:PasswordStrength page, for those that want to check

Maybe we can only display the meter when someone with privileges sets their password?

And we could run that meter on login phase as well perhaps, at least if someone's permisisons were recently changed, or if he has elevated privileges

@TheDJ we might as well just stick PasswordStrength onto the create account page since it would make the purpose pointless if we just create a separate special page for user's to check. Since it will probably not be used that much then if we do it on the login page it will be used all the time because it will do it automatically without users having to tick anything else or do anything else.

But then again we could create PasswordStrength for already created users that want to check there password strength but we should also add this to change password too.

The state of the art in password strength check is probably zxcvbn from Dropbox. It does not seem i18n-friendly but maybe that can be hacked on top.

Apparently this was added then removed in 1.17 ($wgLivePasswordStrengthChecks).

It was removed by @Catrope in https://phabricator.wikimedia.org/rSVN81445

More research behind usefulness of strength meters, citing security engineer A. Smolen:

Research shows mixed results, see https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/ur
Even without meter, client-side validation of acceptability is important.

In T32574#2804184, @Volker_E wrote:

Even without meter, client-side validation of acceptability is important.

That depends on T111303: Create password verification API with AuthManager.

I did a little poking at this today. It turns out not to be too hard to put zxcvbn in an extension and inject a field into AuthManager's HTMLForms to display a strength indicator just below the password field.

But the dictionaries might be problematic: zxcvbn has 755K of dictionaries, that are oriented towards English. Would it blow up ResourceLoader somehow (e.g. cache in LocalStorage) to be pulling down 775K of dictionaries? How could we handle non-English dictionaries? Could we put them in 300K-each i18n messages, or would that destroy MessageCache?

That's huge. Can't they be compressed to be smaller?

In any case, I don't think i18n messages are good fit for this data, even if it could work. Those are too big to translate and would make editing those files hard, unless they are placed in separate files, at which point I would just consider loading them out-of-band with ajax.

The dictionaries can potentially cause performance issue. If we are looking for a system that can give password strength ranking(non binary result, API might be the best solution. If we are ok with week or strong binary result, a bloom filter based space efficient test is a choice. https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/ explains why they did not choose bloom filter - they wanted the dictionary adaptive and providing ranks instead of membership tests. If we can compromise on those requirements, bloomfilter may be alternative.

In T32574#2836570, @Anomie wrote:

Would it blow up ResourceLoader somehow (e.g. cache in LocalStorage) to be pulling down 775K of dictionaries?

Nope, it would not :)

We already reject module sources larger than 100K from being stored in LocalStorage (source). This to make optimal use of the limited space (5MB) by storing as many smaller modules as possible, which serves the mw.loader.store's primary purpose of reducing HTTP cache fragmentation from differing module batches from one page to another, and to reduce bandwidth when requesting the same batch after only one of the modules changed.

Instead, larger modules are always fetched using HTTP, which still allows stable and long-lived client-side caching through the browser's HTTP cache.

Change 434105 had a related patch set uploaded (by Edlira; owner: Edlira):
[mediawiki/core@master] Add password strength policy to validate the password.

https://gerrit.wikimedia.org/r/434105

the library used seems excellent. the usage i am not so sure, it is a mandatory check, and not a hint to the user:

		if ( $score < $policyVal ) {
			$status->error( "passwordpolicies-policy-passwordstrength", $score, $policyVal, $maxScore );
		}

imo it should return the value and show it to the user in a password meter. here the NIST recommendations, saying "... Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter":
https://pages.nist.gov/800-63-3/sp800-63b.html

an example password strenght meter:

• demo: https://cups.cs.cmu.edu/meter/
• mentioned in this article: https://phys.org/news/2017-05-unveil-password-meter-users-passwords.html.
• source is here: https://github.com/cupslab/password_meter

Currently a password policy is a PHP method that returns a Status (ie. success or a list of error messages). For a nice UX, it should at least consist of:

• A message explaining the requirement (as users should not be forced to discover it by trial and error). The site admin could use some message instead (signupstart etc) but that's not very nice.
• A PHP method checking that requirement. It does not necessarily have to return a message (as we would already have the message describing it, so it's enough to color that to green if it passed, red if it failed, black initially), although there might be cases where we might want to return more information.
• A ResourceLoader module for repeating the same check server-side (and color messages the same way), as-you-type if possible.

Although the Status is also used to tell if the weak password should be rejected or accepted with a warning, so that is still needed.

Any updates?

@Daylen: See the patch: It requires more fixes. Would you fancy doing that?

Change 478456 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/vendor@master] Add bjeavons/zxcvbn-php

https://gerrit.wikimedia.org/r/478456

I feel using zxcvbn as a standard password policy check is not good UX. One issue is that it can change in volatile ways as it is based on fuzzy-matching passwords to dictionary words (and changes to that logic can have non-trivial effects on a given password - see the examples linked in T211489#4808424). We don't want existing passwords to be invalidated when someone tweaks the logic, or adds a new dictionary - the level of user annoyance would not be in line with the benefits. So I think this should be used strictly for checking new passwords, and not for checking existing passwords on login.

Also, there should be feedback on why the password is bad - zxcvbn tells you what are the dictionary words in the password, and some other things, and without expressing those to the user, just telling "this password is weak, please pick a strong password" seems not so useful.

I filed T211514: $wgPasswordPolicy should be able to alter the password form field and T211525: $wgPasswordPolicy checks should be able to communicate details to client-side logic via the validatepassword API which I think are prerequisites of doing those things.