MediaWiki r70520 - Code Review

Jump to: navigation, search
Revision:r70519‎ | r70520 (on ViewVC)‎ | r70521 >
Date:19:16, 5 August 2010
Status:reverted (Comments)
JavaScript-based password complexity checker on account creation and password change. Needs attention from CSS gurus to look decently.
Note that OutputPage::addPasswordSecurity() doesn't check the enabling setting to make this code reusable by extensions who don't always want to follow core settings.
Modified paths:

Diff [purge]

Loading diff…

Follow-up revisions

Rev.Commit summaryAuthorDate
r70521Follow-up to r70520: forgot to add new filesmaxsem19:18, 5 August 2010
r70522Restored line accidentally removed in r70520maxsem19:21, 5 August 2010
r70527Message and formatting tweaks for r70520siebrand20:50, 5 August 2010
r70528Message and formatting tweaks for r70520. Forgot to commit this in r70527.siebrand21:17, 5 August 2010
r70536Follow up r70520. More for loop fixes.hartman01:24, 6 August 2010
r70769Fixes for password checker from r70520:...maxsem16:17, 9 August 2010
r70961Follow up r70520. Use canonical class name.platonides14:37, 12 August 2010
r814451.17: Take out r70520 (JS password strength checker)catrope12:24, 3 February 2011
r86157Merge r81445 from 1.17: revert r70520 (js password complexity checker)demon23:38, 15 April 2011
r101520Bug 32125: remove stray $wgLivePasswordStrengthChecks leftover from a reverte...brion20:17, 1 November 2011


#Comment by Nikerabbit (talk | contribs)   19:39, 5 August 2010

Yay great stuff. Few issues:

  • Display is quite ugly (due to layout)
  • Reports everything as BAD for me
  • I don't see the need for a global for this one.
#Comment by MZMcBride (talk | contribs)   20:18, 5 August 2010

I don't know for sure, but I'm assuming that this revision is related to this Signpost piece.

I find the entire idea that you need to be told how strong your password should be for your encyclopedia-editing account to be a bit extreme. It may make some sense for accounts with elevated user rights, but I think this is bad nannying when applied to all users.

#Comment by MaxSem (talk | contribs)   20:19, 5 August 2010

Yes, it gave me the idea.

#Comment by Simetrical (talk | contribs)   20:17, 8 August 2010

I don't think we should have any such password-checker for ordinary users. Ordinary user accounts can do nothing bad if compromised, we should not be trying to scare them into using harder-to-remember passwords. Security vs. convenience falls on the side of convenience here.

If actual password security is desired, it should use an existing well-established system, not a crude one made up by us. Your system rates "password123" as "acceptable", but "mfkropl" as "BAD", although the latter is much less guessable than the former. It labels two of the three most common passwords according to <> "mediocre" rather than "BAD" ("password" and "12345678"). It also seems to assume that nobody uses anything other than ASCII for passwords, which is totally unreasonable. This kind of pseudo-security is just annoying.

Some people might want this kind of silly thing, but I strongly feel that it should be off by default and off on all Wikimedia sites, or preferably relegated to an extension. A much better solution is to use a proper password security checker and make it mandatory for sysops, including prohibiting the promotion of a user to sysop if they don't have a secure enough password.

#Comment by Platonides (talk | contribs)   21:50, 8 August 2010

Ordinary users don't like being compromised more than others. For many people it's an online identity. We could approximate the damage it would do based on account age and activity, but that's unknown when creating the account. I think a good compromise is to show a password strength meter (without enforcing) and recommend using passwords moderate to high (instead of just high).

The problem is on measuring the password strength. As I asked on irc, I'd like to see documented how is it being measured, so that it can be analysed without going down to the code. Ideally, someone would have already studied the problem and we would only need to code the conclusions from a paper.

#Comment by Simetrical (talk | contribs)   22:05, 8 August 2010

Having your account compromised is extremely unlikely, but forgetting your password is common. Both can result in loss of access to the account. We should be encouraging ordinary users to use easy-to-remember (thus probably easy to guess) passwords to reduce the high risk of forgetting passwords, rather than encouraging them to use hard-to-guess (thus probably hard to remember) passwords to reduce the extremely tiny risk of someone trying to guess your password. Someone guessing your password is particularly unlikely for non-admins, since there's no obvious motive, and hackers almost always have a motive.

#Comment by Platonides (talk | contribs)   22:11, 8 August 2010

We should encourage providing an email instead. We can recommend password stores, too.

> Someone guessing your password is particularly unlikely for non-admins, since there's no obvious motive, and hackers almost always have a motive.

  1. You are an admin on a different wiki.
  2. It is a private wiki.
  3. You have 99 positive votes for becoming an admin.
  4. You can approve Good Articles / Flickr licenses...
  5. You tagged my article for deletion!! (I have seen big reactions for the dumbest "articles")

Anyway, the conditions under which the strength meter would be shown are somehting to be defined separatedly.

#Comment by Simetrical (talk | contribs)   15:16, 9 August 2010

Confirming an e-mail is a pain, and many people change their e-mail address every few years (moving to different providers, changing name, etc.). People also might not want to give their e-mail to avoid spam.

I don't object to having a strength meter somewhere, as long as it doesn't use really stupid heuristics (which 98% of password strength meters do), but I strongly feel it should be off by default for all users, and off on Wikimedia for new users.

#Comment by 😂 (talk | contribs)   15:19, 9 August 2010

What about putting it on Special:ResetPassword but not on the sign-up screen? It would keep us from being off-putting to people signing up, but still allow for suggestions/strength feedback when they're changing their password.

Agree 100% that it should be based on good heuristics.

#Comment by Simetrical (talk | contribs)   15:21, 9 August 2010

If it's reasonably pretty and unobtrusive and uses smart heuristics, then maybe that would be okay. None of those three conditions hold right now, though, so it should still be disabled by default until then. We should not be jumping on security-theater bandwagons that don't actually benefit our users more than annoy them.

#Comment by Nikerabbit (talk | contribs)   15:24, 9 August 2010

Don't you have a bit extreme position here? If they think wmf is going to send spam, they are probably also going to use strong passwords. Regardless, we are not forcing anything here, just giving user a good feeling and confidence if they happen to choose a good password. And yes the meter should be fixed (it's broken like I said above) and the heuristics should be made more appropriate.

#Comment by Simetrical (talk | contribs)   22:02, 12 August 2010

I just don't think we should encourage regular users to use strong passwords at all. They should use weak, easy-to-remember passwords in preference to strong, hard-to-remember passwords. The risk of forgetting their password is much greater than the risk of someone else guessing their password, and the two scenarios are equivalently damaging (loss of access to account, no real damage done). Putting up a password strength meter encourages users to choose strong, hard-to-remember passwords, which is bad in the case of Wikipedia. Having your account compromised is only worse than forgetting your password when the attacker can cause damage or view private information, and that's not the case on normal wikis.

#Comment by Platonides (talk | contribs)   19:52, 9 August 2010

Note that you don't need to confirm the email for password reset, only to use Special:EmailUser.

#Comment by Preibusch (talk | contribs)   13:24, 9 August 2010

It may not be the best available solution, but it is documented and deployed: Microsoft Password checker <>, with underlying design choices <>. This implementation differs from the one currently deployed on Also, neither of these two flag passwords made up of sequences of adjacent keys (e.g. "1qaz2wsx").

#Comment by Platonides (talk | contribs)   13:51, 9 August 2010

They are tips more than a documentation, but useful as well.

A shortcoming of that password checker (which is quite common) is that it considers "123456$a" as strong but "ryfewtyajfyknelzqthhbhbxfckxrxyesamwemuugkhzrvkfepzdmrpmfyleaoktjzxusmbvtweixrfz" weak whereas the first has about 6.5536e+12 (408) bits of entropy and the second 1.57713125193e+113 (2680)

#Comment by MaxSem (talk | contribs)   05:28, 26 January 2011

Meh, let's just not include this in 1.17.

#Comment by Catrope (talk | contribs)   21:27, 2 February 2011

I tried taking it out of 1.17, but it's getting kind of annoying, so I'd rather just leave it in and leave it disabled by default.

#Comment by Catrope (talk | contribs)   12:26, 3 February 2011 what I said when I was almost falling asleep on my keyboard. 11 hours of sleep later, it was actually fairly easy. Taken out of 1.17 in r81445.

Status & tagging log