Last modified: 2011-03-13 18:05:21 UTC
Problem: say an open proxy or whatnot repeatedly tries to log in as various sysops. Say it even triggers lockouts and e-mails and alerts per bug 9836. But there's no way to stop it. Block the IP? Can still log in if it gets a correct password, can immediately unblock itself and wreak havoc. Obvious solution: permit some way to block IPs from even logging in. Problem with obvious solution: collateral damage. Currently users can happily log in with Tor or whatever they want, and for some (China, etc.) this might even be necessary; if some clown gets open proxies blocked from logging into a wiki as sysop, some users might be inconvenienced or even unable to edit. So a more careful solution is needed. The obvious solution to the problem with the obvious solution is more granularity, e.g., make it possible to block open proxies from logging in as admins except for certain exempted admins who actually need/want to use open proxies. Unfortunately, that's complicated, but I can't see any other way to avoid the problem, and ignoring the problem appears unacceptable. However this works, obviously no confirmation or disconfirmation of the entered password should be given, i.e., no message like "you would have successfully logged in except that your IP is blocked"; that would obviously defeat the purpose. It has to be "we didn't even look at your entered password because your IP is blocked from logging in". It would seem like this should be a dupe, probably of a WONTFIX, but I can't find anything.
Having more secure passwords will solve this problem with much less trouble and complexity. And yes, China will be a huge problem with blocking open proxies. MSN or hotmail or whatever (not google) has a nice password-strength requirement. The password "password", "123456", etc. are rejected. We might wish to implement something like this; it should be somewhat easier to code and should be easier on the servers.
(In reply to comment #1) > Having more secure passwords will solve this problem with much less trouble and > complexity. And yes, China will be a huge problem with blocking open proxies. > > MSN or hotmail or whatever (not google) has a nice password-strength > requirement. The password "password", "123456", etc. are rejected. We might wish > to implement something like this; it should be somewhat easier to code and > should be easier on the servers. That is Bug 3348.
(In reply to comment #1) > Having more secure passwords will solve this problem with much less trouble and > complexity. It won't solve the problem. Passwords can still be brute-forced, and if it takes a month and ten million guesses to do it, why does a hacker care if he can't be stopped regardless? Arguably more secure passwords *plus* captchas will solve it, but that assumes that the captchas are unbreakable, which they certainly aren't. They're just sufficiently difficult to deter less proficient hackers. It makes the problem a relatively unimportant one, but not necessarily one that's not worth addressing at some point, especially as Wikipedia's profile continues to grow. This could be per-account, as I said. Thus admins from China who need to use open proxies can indicate that they should be allowed to log in from them, whereas the overwhelming majority who don't use open proxies can prohibit login attempts from those. Maybe a too minor problem to bother fixing in the foreseeable future, I'll grant. We'll see how long new security measures hold off attackers.
I'm changing this to WONTFIX. This is just asking for a DOS attack. All it takes is for one person from Qatar to request an admin's password and for that admin to freak out and block the ip from logging in. With the captchas / throttles in place there shouldn't be much (if any) danger of brute-forcing that a log-in block could help to fix.
