Author: ebe123_wiki
Description:
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.
Version: unspecified
Severity: enhancement
Author: ebe123_wiki
Description:
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.
Version: unspecified
Severity: enhancement
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/vendor | master | +2 K -1 | Add bjeavons/zxcvbn-php | |
mediawiki/core | master | +67 -1 | Add a password policy to validate strength via zxcvbn |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | • chasemp | T121186 Implement results of enwiki Security review RfC | |||
Open | None | T32574 Display a password strength bar | |||
Resolved | Anomie | T111303 Create password verification API with AuthManager | |||
Resolved | Anomie | T47843 Rework API error reporting | |||
Open | None | T151011 Add password generator to account creation / password change form | |||
Open | None | T211489 Security review of bjeavons/zxcvbn-php |
(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
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.
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.
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.
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.
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:
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:
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.
Change 478456 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/vendor@master] Add bjeavons/zxcvbn-php
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.
Change 478456 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/vendor@master] Add bjeavons/zxcvbn-php