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