New extension to enforce minimum password strength.
OpenPublic

Description

Author: mike.lifeguard+bugs

Description:
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


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44788
https://bugzilla.wikimedia.org/show_bug.cgi?id=25925

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz16435.
bzimport created this task.Via LegacyNov 23 2008, 3:22 AM
IAlex added a comment.Via ConduitNov 27 2008, 10:06 PM

Note: Minimal password lenght is already configurable with $wgMinimalPasswordLength (http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).

bzimport added a comment.Via ConduitDec 18 2008, 4:14 AM

mike.lifeguard+bugs wrote:

(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).

The_RedBurn added a comment.Via ConduitFeb 19 2009, 5:17 PM

(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).

bzimport added a comment.Via ConduitFeb 19 2009, 5:41 PM

mike.lifeguard+bugs wrote:

(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.

demon added a comment.Via ConduitFeb 19 2009, 7:58 PM

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?

The_RedBurn added a comment.Via ConduitMay 5 2009, 9:00 AM

(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.

demon added a comment.Via ConduitDec 4 2010, 6:59 PM

I think between those two things we can call this FIXED.

Issues or enhancements with either should go as their own bugs.

Mattflaschen added a comment.Via ConduitFeb 8 2013, 7:28 AM

Note that wgLivePasswordStrengthChecks was removed. See https://www.mediawiki.org/wiki/Manual:$wgLivePasswordStrengthChecks

MZMcBride added a comment.Via ConduitFeb 8 2013, 7:32 AM

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.

Mattflaschen added a comment.Via ConduitFeb 8 2013, 7:48 AM

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.

Add Comment