New extension to enforce minimum password strength.
Open, NormalPublic

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.Nov 23 2008, 3:22 AM

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

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

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

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.Feb 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?

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

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.

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