Last modified: 2011-03-13 18:05:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T11837, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9837 - Allow IPs to be blocked from even logging in (for certain accounts only?)
Allow IPs to be blocked from even logging in (for certain accounts only?)
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 9816
  Show dependency treegraph
 
Reported: 2007-05-08 01:09 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-08 01:09:01 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.
Comment 1 Kevin Yin 2007-05-14 05:46:21 UTC
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.
Comment 2 Titoxd 2007-05-14 19:54:03 UTC
(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. 
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-15 00:39:50 UTC
(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.
Comment 4 Daniel Cannon (AmiDaniel) 2007-08-26 05:03:34 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links