Last modified: 2009-06-09 20:03:50 UTC
The Extension:Passwordstr purposely weakens user password strengths by excluding many possible passwords from the choices, users can make. By its regexp rules, many of which can easily be determined automatically, brute force password cracking automats can spare some tests and thus find passwords faster. We should recommend not using this kind of pseudo-wannabe-security. Better delete the extension altogether.
Nobody is forced to use it.
I don't see how this reduces password security. Knowing how many digits must be in a password doesn't tell you how many are in one, nor does it tell you how many the average person uses. Same for upper/lowercased numbers. Not to mention: a regex block just blocks a certain format, it doesn't tell you what the password *should* be. Suggestions on how to improve it are welcome, but a blanket "its bad and take it away" isn't helpful. A very good use case would be internal wikis (of which there are many). A company might want their users to use strong passwords, but in reality the chances of someone trying to brute force MediaWiki passwords on an internal network is low. (Switching to extensions because this isn't in core)
Unrelated to this bug, but the problem I see in this extension is that it can be used to force to have ascii characters in passwords, which might not be nice for languages using other scripts.
@demon: I won't explain why reducing the number of possible choices reduces password security. Read basic texts on the subject matter. The only potentially productive thing towards more security that this extension could do was enforcing a minimum password length. Forcing specific sets of symbls into passwords (digits, ASCII, interpunctuation, lowercase, uppercase, etc.) reduces passwort security in general. If this extension is not deleted, the we MUST clearly caution potential users not to use such counterproductive kinds of rules, unless they really WANT to weaken statistic security.
Fair enough. I'll nuke it this afternoon.
Gone as of r47762.
(In reply to comment #4) > @demon: I won't explain why reducing the number of possible choices reduces > password security. Read basic texts on the subject matter. It doesn't materially reduce the number of possible choices. The number of possible choices in any event is roughly 2^x, where x is the max POST size in bits. Typically x will be on the order of at least 10,000,000, and even banning all Unicode characters will not reduce this a whole lot. I think this kind of extension is really annoying, and a much better implementation would be to rely more on dictionaries and length. carnivorousstegasauroid is a lot more secure than Password1234, but the former would probably be banned by many simplistic password strength checkers when the latter would not. But it prevents people from using passwords like "password" and so is almost certainly an increase in security -- I think the reason for deletion is bogus. If the extension encourages banning non-ASCII characters, this should be fixed. It can be done without deleting the whole extension.
(In reply to comment #3) > Unrelated to this bug, but the problem I see in this extension is that it can > be used to force to have ascii characters in passwords, which might not be nice > for languages using other scripts. The solution would be to replace /[0-9]/, /[A-Z]/ and /[a-z]/ regex with \p{N}, \p{Ll} and \p{N} (In reply to comment #7) > I think this kind of extension is really annoying, and a much better > implementation would be to rely more on dictionaries and length. > carnivorousstegasauroid is a lot more secure than Password1234, but the former > would probably be banned by many simplistic password strength checkers when the > latter would not. Completely agree. Perhaps instead of measuring that it contains many characters we should measure the number of possibilities on that subset So the first one would have 23*26 = 588 points of password strength (23 lower case letters) and the second one 12*(2*26+10) = 744 password strength points (12 uppercase, lowercase and numers). That could them refined. The second one could instead be considered as 8 letters followed by 4 numbers: 8*2*26 + 4*10 = 456 The difficulties arise in determining how large is the "letters" block for non-western languages. But even if only detecting weak passwords on latin1, it could prove useful. Another option would be using that system as a javascript password strengh measurer.
(In reply to comment #8) > Completely agree. > > Perhaps instead of measuring that it contains many characters we should measure > the number of possibilities on that subset > So the first one would have 23*26 = 588 points of password strength (23 lower > case letters) and the second one > 12*(2*26+10) = 744 password strength points (12 uppercase, lowercase and > numers). > > That could them refined. The second one could instead be considered as 8 > letters followed by 4 numbers: 8*2*26 + 4*10 = 456 One way I've seen it done is to say something like "Minimum length 12 characters. -1 if it contains [a-z], -1 if it contains [A-Z], -1 if it contains [0-9], -1 if it contains other printable ASCII, -2 if it contains non-ASCII", with all the minuses stacking. Then you could use a six-character password, as long as it was something like aAa1!א. This particular heuristic still discriminates against non-English languages (Chinese people need to have entire sentences as passwords?!), but it could be refined.
So what is the use of having this issue reopened? It is now a feature request to have a password strength extension, or just some discussion? Please deal with it appropriately.
No reason to keep it open. If someone else wants to implement such a system, they're more than welcome. PasswordStrength has been deleted and I'm not planning to resurrect it.
