Last modified: 2013-02-12 17:54:09 UTC
There is an issue at [[:de:Wikipedia:Fragen zur Wikipedia#Mindestlänge bei Passwörtern]] to have a larger minimum password length. It is still at 1, which some think is to low. Is it /possible/ to raise it, or: What would happen to users with to short passwords? In the linked disc there also was the idea to have different minmium lengths dependig on the usual alpahabet; for example it could be lower in the Chinese projects than in such with a latin charset. Related to Bug 16435.
They would currently be unable to login until they request a new password by email.
How many would be affected by this? Do the server admins have access to these password data to inform everybody whose password is to short? Otherwise we'd have to change the MediaWiki-messages login* to warn them. Are there some who had not specified a e-mail-address? Their accounts would get locked. But I dont think there are a lot of these or their contributions to important.
Password are encrypted with md5 and salted. We cant reliably detect short passwords.
Actually, bruteforcing 1-char password is easy, despite even salt.
Another option is to allow login once with a one character password, forcing them to change it.
(In reply to comment #3) > Password are encrypted with md5 and salted. I thought as much. Bruteforcing is neither a solution, it might be possible for 1-char passwords, but 2 or 3 are also not save enough. (Also imagine about the PR: "Wikipedia admins hack their users' passwords!" :-) (In reply to comment #5) Good idea, but not as easy to code as I supposed at first. And you can't guarantee that any user would login another time... But a new variable like $wgMinimalPasswordLengthForNewRegistrations sounds well. Together with the force to change it would imho solve the problem.
As I've remarked elsewhere repeatedly and at length, I don't think unprivileged users should have any password strength requirements. It hurts them and no one else if their account is compromised, so they can make the convenience vs. security decision for themselves. Ideally, strict password strength requirements should be imposed on sysops and bots. But if a wiki did want this anyway, I definitely would say that making $wgMinimalPasswordLength not prevent login is a blocker. It's not reasonable to disable thousands of accounts just because we've strengthened password policy. (BTW, I tried running a query as root on the toolserver to see how many users had ' ' as a password, but it's taking an awfully long time. It's possible to do, but I doubt it's worth it except for sysops.)
(In reply to comment #7) > (BTW, I tried running a query as root on the toolserver to see how many users > had ' ' as a password, but it's taking an awfully long time. It's possible to > do, but I doubt it's worth it except for sysops.) root@sql-s2:dewiki> SELECT COUNT(*) FROM user WHERE (user_password LIKE ':B:%' AND SUBSTR(user_password, 13) = MD5(CONCAT(SUBSTR(user_password, 4, 8), '-', MD5(' ')))) OR (user_password LIKE ':A:%' AND SUBSTR(user_password, 4) = MD5(' ')) OR (user_password NOT LIKE ':%' AND user_password = MD5(CONCAT(user_id, '-', MD5(' ')))); +----------+ | COUNT(*) | +----------+ | 62 | +----------+ 1 row in set (33.86 sec) Not actually that long, it would be easily doable to detect such users with a maintenance script. But what would we want to do with them?
That they can't login with a password too short was done on purpose in r9312
Bug 16435 points to SecurePasswords that, if dewiki wants, can be installed after a review by the Release Manager. I think installing that is a better choice than blocking users from logging in because you don't think their passwords are long enough.
I don't think we should guarantee that users with very weak passwords (say under 6 characters, but we could draw the line elsewhere) should be able to log in forever (without changing or resetting the password). It was a mistake to ever allow such passwords, but we don't need to keep perpetuating the mistake forever. If we were to do this, though, we would want to clearly notify affected users ahead of time, particularly those without an email account (needed for reset). We could consider notifying them at login time for a certain period and/or requiring a password change, before blocking login/requiring reset. Another option is to only make this change for users with elevated rights (e.g. admins).
(In reply to comment #11) > I don't think we should guarantee that users with very weak passwords (say > under 6 characters, but we could draw the line elsewhere) should be able to > log in forever (without changing or resetting the password). > > It was a mistake to ever allow such passwords [...] Why a mistake? You know, before the minimum password length was 1, it was 0. I seem to remember Brion saying that he used to log in with a blank password. Many others did as well. The vast, vast majority of MediaWiki accounts have almost no value, as Aryeh and others have argued (cf. comment 7 and r70520). I'd consider locking thousands of users out of their accounts to be a nuclear option. > Another option is to only make this change for users with elevated rights > (e.g. admins). Right. This approach makes more sense. This is mostly covered by bug 16435. The idea is that accounts with elevated privileges (administrator, CheckUser, oversight, etc. accounts) could require a stronger password. Of course, with logins still not required to use HTTPS, a lot of these security measures look rather silly. Footnotes: * bug 621 comment 1 * bug 1448 comment 3 * bug 4063 comment 1 * bug 9834 comment 0 * bug 30574 comment 3
(In reply to comment #11) > Another option is to only make this change for users with elevated rights > (e.g. admins). +1.
> Why a mistake? You know, before the minimum password length was 1, it was 0. I know that. I haven't heard a good explanation of why it was bumped only to 1, rather than something more reasonable. It was a mistake originally since we let users (many of whom definitely don't understand the issue) use extremely weak passwords. Yes, they may use a weak password either way, but at least not "pick a number between 1 and 36 weak". I agree it's a far more important discussion for users with elevated rights, but that doesn't mean we should necessarily take no action for regular editors. Bug 16345 was just about writing an extension. The initial comment did say "enforce varying levels of password security by user group (ie admins have an intermediate level, stewards must have a high level)". But it doesn't look like Extension:SecurePasswords, which was given as a reason to close the bug, does that in any way. I've opened bug 44788 specifically for password requirements by group.
"Of course, with logins still not required to use HTTPS, a lot of these security measures look rather silly." There are different attack scenarios, all of which should be dealt with. HTTPS is certainly very important for the eavesdropping scenario. However, password brute-forcing can be used against anyone, even those who always use HTTPS.
Our rationale for keeping the behaviour where we lock people out of their account simply by trying to require new passwords to be sane smells a little like BS. From the looks of it so far the only rationale put forward is "because r9312 did it". And r9312's rationale looks like "Since we can't stop passwords below the minimum length being saved in 3rd party auth systems, we'll just not permit users to login instead." Which frankly doesn't fit right now. Since this feature that is supposed to protect us from 3rd party auth plugins is taking effect when absolutely no such auth system is in use. And instead of protecting users it's preventing us from gracefully migrating to a better default password strength. At the very minimum this feature should have a way of disabling it so that wikis can migrate users. And as a footnote. I think the default minimum for MW should be at the very least, 6. Although 8 may be a little more sane.
(In reply to comment #15) > However, password brute-forcing can be used against anyone, even those who > always use HTTPS. To what end?
Could we not program it to prompt the user to change their password if its "weak"/"under the X character count"? which would seem to solve most of the issues/arguments presented here about locking people out.
(In reply to comment #17) > (In reply to comment #15) > > However, password brute-forcing can be used against anyone, even those who > > always use HTTPS. > > To what end? To get into their account, the same reason an attacker brute-forces anyone. I don't know what you're getting at. Like I said, there are different attack scenarios. (In reply to comment #18) > Could we not program it to prompt the user to change their password if its > "weak"/"under the X character count"? which would seem to solve most of the > issues/arguments presented here about locking people out. So never lock anyone out, but force a change on login? That seems like a potentially reasonable approach for non-privileged accounts. It still leaves inactive accounts with a weak password, but ensures migration of actively used accounts over time.
(In reply to comment #19) > (In reply to comment #17) >> (In reply to comment #15) >>> However, password brute-forcing can be used against anyone, even those who >>> always use HTTPS. >> >> To what end? > > To get into their account, the same reason an attacker brute-forces anyone. > I don't know what you're getting at. Like I said, there are different attack > scenarios. Okay, keep going. They get into someone's account, and then what? I don't see the attack scenario.
> Okay, keep going. They get into someone's account, and then what? I don't see > the attack scenario. They impersonate them, then edit (and maybe email) under their name. Maybe you think that's irrelevant for regular editors. I think it's still a serious problem, just not as big a problem as if the same thing happens for someone with elevated rights.
(In reply to comment #21) > They impersonate them, then edit (and maybe email) under their name. > > Maybe you think that's irrelevant for regular editors. I think it's still a > serious problem, just not as big a problem as if the same thing happens for > someone with elevated rights. It's only serious if you can justify why it's serious. People can edit without logging in at all. And they can make as many free accounts as they'd like. So... why would they hack into someone else's account? Many smart people here and elsewhere have said that it's up to users to define what level of security they're interested in placing on their account. And many users rightly choose a weak password, as the ability to remember a password is more important than the almost non-existent possibility of their valueless account being hacked. That point still seems to be getting lost somewhere. Security measures always come with a cost, both in terms of technical debt and in terms of user experience. I'm not sure these costs are being properly considered.
Well, impersonating the random User:!!!!HAGGER!!!!! is probably less useful (and harmful) than impersonating any random living and possibly important person just by editing via IP. UseModWiki allows you to edit as "registered" editor just by entering the desired name and it's still going strong. ;-) Seriously, whatever "solution" locks out unprivileged users does more harm than good. Can we just acknowledge this and move on? This discussion is getting boring and every additional comment makes this bug more unlikely to be fixed.
> Okay, keep going. They get into someone's account, and then what? I don't see the attack scenario. Obtain credentials for an admin account, edit a few lines of JS in the MW namespace, take down wikipedia (or any other website prominently linked from it, SOPA-style DDoS)?
I'll add some non-admin attack scenarios: * With our rate limits what they are, you can actually brute force single-character passwords (15-30 mins each, before you optimize for user bias in choosing the single digit) faster than the creation rate limits (4-6/day for most wikis). So spammer wants some accounts? * Editors get in an edit dispute, one editor brute forces the other's login, vandalizes, gets the other person blocked. One proposal I'll make is to remove the check that the password meets the minimum length on login, and enforce it on account creation and password change. That (I think, although I haven't traced all the code) would let us raise it for new accounts without locking out the old ones. Daniel and Tyler were working on a password backend rework last summer, that I'm really sorry I missed pushing internally. Both, iirc, prompted for a password change on login if the user's group membership required more complexity, which is the right way to go in the long run, imo.
(In reply to comment #24) >> Okay, keep going. They get into someone's account, and then what? I don't see >> the attack scenario. > > Obtain credentials for an admin account, edit a few lines of JS in the MW > namespace, take down wikipedia (or any other website prominently linked from > it, SOPA-style DDoS)? Privileged accounts are mostly a separate discussion (bug 44788). When discussing accounts generally, 99.99% of them are unprivileged. $wgMinimalPasswordLength applies to all accounts. Again, in terms of weighing cost v. benefit, inconveniencing 99.99% of users because .01% of users could maybe be disruptively hacked doesn't seem like a reasonable trade-off.
(In reply to comment #25) > * With our rate limits what they are, you can actually brute force > single-character passwords (15-30 mins each, before you optimize for user > bias in choosing the single digit) faster than the creation rate limits > (4-6/day for most wikis). So spammer wants some accounts? Why wouldn't the wannabe spammer just edit logged out? Or make their own accounts? The effort required to bypass the account creation restrictions is surely lower than the effort required to brute-force random accounts. > * Editors get in an edit dispute, one editor brute forces the other's login, > vandalizes, gets the other person blocked. You're certainly getting more creative, but this still comes down to user choice regarding account security. And this scenario seems to be fairly far-fetched and still not worth the inconvenience.
(In reply to comment #25) > One proposal I'll make is to remove the check that the password meets the > minimum length on login, and enforce it on account creation and password > change. That (I think, although I haven't traced all the code) would let us > raise it for new accounts without locking out the old ones. > > Daniel and Tyler were working on a password backend rework last summer, that > I'm really sorry I missed pushing internally. Both, iirc, prompted for a > password change on login if the user's group membership required more > complexity, which is the right way to go in the long run, imo. I think together these are a reasonable middle ground.
I do not think you should continue arguing on this bug report :-] Maybe you want to open a request for comment at http://www.mediawiki.org/wiki/Requests_for_comment It could list all possible cases and match it with a MediaWiki behavior for it. Once we get some kind of workflow we can actually start implementing and finally fix that years old bug :-] I will be more than happy to review such a document and give my input.
(In reply to comment #25) > Daniel and Tyler were working on a password backend rework last summer, that > I'm really sorry I missed pushing internally. Both, iirc, prompted for a > password change on login if the user's group membership required more > complexity, which is the right way to go in the long run, imo. Actually there was no password change in that project. The goal wasn't to change the actual password but make it so that password hashes were upgraded when you login. eg: A user with an :A: type password would login with their password 'password', their password would stay as 'password' but the password hash for their account would be upgraded to say a :C: if that's the latest type the wiki is using. (The new default being PBKDF2-HMAC-SHA256 with a 64 bit salt and 10000 iterations.) And MZMcBride... your talkink about user convenience. But convenience<->security is always a matter of the right balance. And frankly. The difference in convenience between a user being forced to type 'a' and a user being forced to type 'mypass' or 'password' is so small compared to the security difference (potentially seconds vs. days vs. years) that the level of convenience offered by permitting 'a' as a password is unacceptable.
(In reply to comment #29) > I do not think you should continue arguing on this bug report :-] Maybe you > want to open a request for comment at > http://www.mediawiki.org/wiki/Requests_for_comment +1. $wgMinimalPasswordLength is obviously not (currently) the solution. Per Aryeh on comment 7, and the "middle ground" on comment 28 and comment 25, marking this WONTFIX. Of course the discussion about this specific request can continue, but actual plans go in another direction (something is moving, it's a good thing!) and the proper discussion venues do not include this bug...
I've started an RFC. I based it on Chris's idea, and tried to keep it simple: https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements I have also posted this to wikitech-l. By the way, the hash improvements Daniel is talking about (e.g. bug 28419) are very worthwhile, but a separate topic.
(In reply to comment #30) > And MZMcBride... your talking about user convenience. But > convenience<->security is always a matter of the right balance. And frankly. > The difference in convenience between a user being forced to type 'a' and a > user being forced to type 'mypass' or 'password' is so small compared to the > security difference (potentially seconds vs. days vs. years) that the level > of convenience offered by permitting 'a' as a password is unacceptable. The security difference is almost certainly negligible between a password of "a" and a password of "mypass". It would only make a difference if a theoretical hacker used a very linear process to crack passwords (starting with one character, then two, then three), but in reality, nobody would ever crack a password like this.
