Last modified: 2013-02-12 17:54:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16435 - New extension to enforce minimum password strength.
New extension to enforce minimum password strength.
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 9816
  Show dependency treegraph
 
Reported: 2008-11-23 03:22 UTC by Mike.lifeguard
Modified: 2013-02-12 17:54 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mike.lifeguard 2008-11-23 03:22:04 UTC
Apparently Brion ran at least once a "password cracker" (http://meta.wikimedia.org/wiki/Talk:Stewards#Proposed_security_policy). While that's useful to identify vulnerable accounts, it is perhaps best to enforce minimum password strength from the get-go.

This extension should have the ability to
*force users to reset their password every X timespan
*enforce minimum password length
*enforce varying levels of password security by user group (ie admins have an intermediate level, stewards must have a high level)
*bug 9838 Send notification to account owner on multiple unsuccessful login attempts
*maybe other stuff I've not thought about
Comment 1 Alexandre Emsenhuber [IAlex] 2008-11-27 22:06:08 UTC
Note: Minimal password lenght is already configurable with $wgMinimalPasswordLength (http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).
Comment 2 Mike.lifeguard 2008-12-18 04:14:17 UTC
(In reply to comment #1)
> Note: Minimal password lenght is already configurable with
> $wgMinimalPasswordLength
> (http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).
> 

Yes, but this should verify password /strength/

For example, on the toolserver, you cannot set a password with dictionary words (longer than X chars, I think), and you must include 3 of 4 character classes or something (lower case, uppercase, numbers, special chars...?). And so on (presumably the programmers know better than I do what makes a strong password).
Comment 3 Thomas Bertels 2009-02-19 17:17:18 UTC
(In reply to comment #2)
> Yes, but this should verify password /strength/
> 
> For example, on the toolserver, you cannot set a password with dictionary words
> (longer than X chars, I think), and you must include 3 of 4 character classes
> or something (lower case, uppercase, numbers, special chars...?). And so on
> (presumably the programmers know better than I do what makes a strong
> password).
> 

Since there's a captcha after 3 attempts and a temporary lockout after 3 (or so) more attempts, I'm not sure if it's a good idea to enforce that much brute force or dictionary resistant passwords.
Too strong passwords would be difficult for the users to remember.
What about just letting the user know about his/her password strength ?

However, since the compromised accounts passwords were either the same as the login or just "password", those are basic rules to improve password strength (they are probably already active).
Comment 4 Mike.lifeguard 2009-02-19 17:41:33 UTC
(In reply to comment #3)
> Since there's a captcha after 3 attempts and a temporary lockout after 3 (or
> so) more attempts, I'm not sure if it's a good idea to enforce that much brute
> force or dictionary resistant passwords.
> Too strong passwords would be difficult for the users to remember.
> What about just letting the user know about his/her password strength ?
> 
Yes, that'd be nice too. I know of several sites which have a password strengh indicator beside the input which changes as you're typing from "empty" in grey -> "weak" in red -> "OK" in yellow -> "strong" in green using AJAX.

> However, since the compromised accounts passwords were either the same as the
> login or just "password", those are basic rules to improve password strength
> (they are probably already active).
> 
I'm not sure what you mean here... Are there already restrictions on using "password" as the password, or using your username as the password? That good, but we can do better.
Comment 5 Chad H. 2009-02-19 19:58:53 UTC
Fwiw, I've already got an extension in SVN (PasswordStrength) that requires some heuristics on changing password.

Maybe the features described here could be incorporated?
Comment 6 Thomas Bertels 2009-05-05 09:00:35 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Since there's a captcha after 3 attempts and a temporary lockout after 3 (or
> > so) more attempts, I'm not sure if it's a good idea to enforce that much brute
> > force or dictionary resistant passwords.
> > Too strong passwords would be difficult for the users to remember.
> > What about just letting the user know about his/her password strength ?
> > 
> Yes, that'd be nice too. I know of several sites which have a password strengh
> indicator beside the input which changes as you're typing from "empty" in grey
> -> "weak" in red -> "OK" in yellow -> "strong" in green using AJAX.

It could even be done by JavaScript only, by the way (unless we check against a dictionary).

> > However, since the compromised accounts passwords were either the same as the
> > login or just "password", those are basic rules to improve password strength
> > (they are probably already active).
> > 
> I'm not sure what you mean here... Are there already restrictions on using
> "password" as the password, or using your username as the password? That good,
> but we can do better.
> 

I mean that we should just require passwords different from the username, and forbid passwords like "password" or so.
Requiring very strong passwords (like letters + numbers) would be an unnecessary annoyance for the user.
Comment 8 Chad H. 2010-12-04 18:59:44 UTC
I think between those two things we can call this FIXED.

Issues or enhancements with either should go as their own bugs.
Comment 9 Matthew Flaschen 2013-02-08 07:28:00 UTC
Note that wgLivePasswordStrengthChecks was removed.  See https://www.mediawiki.org/wiki/Manual:$wgLivePasswordStrengthChecks
Comment 10 MZMcBride 2013-02-08 07:32:11 UTC
This bug doesn't feel fixed to me. In particular, this piece:

(In reply to comment #0)
> * enforce varying levels of password security by user group (ie admins have an
> intermediate level, stewards must have a high level)

doesn't appear to have been addressed. Re-opening for now.
Comment 11 Matthew Flaschen 2013-02-08 07:48:09 UTC
I've opened bug 44788 so we can specifically track that issue.

It's currently sort of in SecurePasswords, though there is no component for that.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links