Last modified: 2013-02-12 17:54:09 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
Note: Minimal password lenght is already configurable with $wgMinimalPasswordLength (http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).
(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).
(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.
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.
http://www.mediawiki.org/wiki/Manual:$wgLivePasswordStrengthChecks and http://www.mediawiki.org/wiki/Extension:SecurePasswords
I think between those two things we can call this FIXED. Issues or enhancements with either should go as their own bugs.
Note that wgLivePasswordStrengthChecks was removed. See https://www.mediawiki.org/wiki/Manual:$wgLivePasswordStrengthChecks
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.