New User Flood

There seems to be a flood of new users, I can only guess that these are not people interested in robocode, but rather some kind of spam bot (or spam bots). We need some way to captcha user creation I think.

While we are at it, remove some of those "new users" without any edits.

I wonder why create spam bots when you can create Robocode bots. :P

Speaking of user removal. How many active admins do we have?

Well a few, for example I don't have access to actual site stuff (so I can't add a captcha).

We could just go through and manually delete them all, but there is no bulk method way to do that (that I know of).

List of those with mediawiki "administrator" access:
AW‏‎, Chase-san‏‎, Darkcanuck‏, David Alves‏‎, GrubbmGait‏‎, Jdev‏‎, MN‏‎, PEZ‏‎, Rednaxela‏‎, Sheldor‏‎, Skilgannon, Skotty‏‎, Voidious, Wompi

List of those with server shell access:
David Alves‏‎, Rednaxela‏‎, Skilgannon, Voidious

The one whose name the server name is under:
David Alves‏‎

The one whose name the domain name is under:
PEZ

The last several times the server needed config maintnance I've dealt with that. I know Skilgannon is also checking in wiki sometimes. Voidious less often recently to my knowledge.

For future reference, you can see who's a wiki administrator or bureaucrat by using the "Group:" filter on the user list page.

Hate to break it to you Chase, but we already have a captcha on user creation. In fact, we have *TWO* captchas (reCaptcha, plus a simple math question presented as an image) required for user creation, and the bots involved in these user creations seem to crack crack both. I tend to wonder if they're using a "mechanical turk" type of system to outsource bulk captcha breaking to humans.

Only reason they very rarely succeed at actually posting content these days, is because of a custom Mediawiki extension I added, which blocks any edits which add new external URL links if the user account was created within X hours of the attempt. (Note, it does not block external URLs that are not formatted as Mediawiki links, such as the participants page of course)

Perhaps I should augment this extension to remove users whose only attempted edits during a 1 week period were blocked in this fashion?

My experience with captcha locked registration, is that at some point someone, most likely a human, provides an answer to at least one question. After this bots will register like crazy. On my site I had non googlable question, which holds bots for a month or two, but sooner or letter they will come.

The only way to deal with it, is to remove old questions and generate new ones.

"Perhaps I should augment this extension to remove users whose only attempted edits during a 1 week period were blocked in this fashion?"

That policy sounds pretty reasonable, as long as it is clearly written somewhere new users would see.

Make it 3 days and that'll do it for me. We should also nuke users without any posts that registered more then 3 days ago as well (and were not added by an admin), or something.

I think there are some features enabled for registered users. Something with cookies but I cannot recall what are they. So, quiet registered users have a right to exist.

But quite folks do not contribute, so it is probably fine to sweep them away as the bot candidates.

There are not a major amount of benefits to being registered aside from posting. I think it keeps your layout and settings and such. But most active people (even readers) have at least one edit under their belt. Since this is about robocode, you usually make a robot and enter it into the rumble.

Actually, now that I think about it. I think Voidious used Asirra to prevent issues on the berrybots wiki. Now asirra is closing down this year, so we can't use that. But there should be some other image based captcha's around.

As we all know, classification is a very difficult AI problem, but is almost trivial for us humans. :)

Usually, it is sufficient to ask what is "2+2", may be in the form "two plus two" so it is not that obvious for a parser. Since, we are fighting attacks not designed against this particular wiki, it will be sufficient. Once, a traitor give the answer to this question to a bot net, we will ask what is 2+3, and so on.

We could just randomize it so it's 17 + 21, and then just tweak the way it is said so it becomes thing likes "one before eighteen plus one past twenty"

Wow, I would not pass such captcha on a first try :). It sounds like the french way to call numbers, which I believe, is not very common.

Oh, hrm, fair point. French numbers are way more difficult then this though. This is just offset them by 1 each.

I decided to try the registration process. We do have a math question and a number image recognition images. But these bots are advanced. They clearly can parse/recognize numbers and do simple math with them.

I think we need at least one captcha which deals with something but numbers and we need it asap. My rss feed is spammed by new registration announcements way more often than I wish to know.

Or, as Rednaxela noted above, they could just be outsourcing it to humans. Though if they are advanced bots, we could try something like Asirra, which makes users select only photos which have a certain type of animal in them, though it seems Asirra itself won't be around for much longer. (Voidious, since you use Asirra for the BerryBots wiki, you may also want to look into a new captcha system.)

We might want to consider locking registration until we can come up with a solution. The wiki isn't particularly active at the moment and there has been 166 registrations since they started on September 23 (and 1 which is questionable). None of them have posted a single thing. That averages about to around 10-11 new users a day.

I guess that would be fine for a few days, but if someone's willing to go to that trouble, why not just implement one of the solutions that have already been proposed, such as deleting accounts that only post with external links in their first few days, or your suggestion to have a hidden textbox that must be left blank?

That's true. I would do it, but I don't have shell access. So we have to wait for one of the senior admins.

Account creation temporarily disabled while I investigate what the best solution will be (starting with taking a close look at the server logs from the bad attempts)

Account creation is re-enabled.

I removed reCaptcha but in exchange made the math question slightly trickier. I also obfuscated the input field name to be a random string, and added two decoy fields like you mentioned Chase. One decoy is also named with a random string of the same form as the real one (and the ordering in the DOM is swapped at random), and the other decoy has the fixed field name that is normally used for a math captcha on Mediawiki.

We'll see if this keeps them out.

While I was at it, I also cleared out inactive users with a maintenance script.

Oh thankyou. That big list of names on the change log was causing me grief (and it made the atom feed about useless). Let's hope that this stall them for awhile. It isn't like they were able to post anyway, but the registration itself was getting annoying.

Thanks for the changes. It is nice to see only relevant changes in the log.

Yeah, thanks for doing that. The recent changes page looks a lot better.

Now that I had some time to think on the problem. I do remember using one really simple and really effective tool to prevent bots from registering.

It's called a reverse captcha. Basically you use in combination with normal captcha, but you are suppose to leave it blank. Give it a id and name like "captcha" and bots will almost always fill it in with something. You then either hide it via css (most bots don't read css, and even if they do, it often falls into the machine vision problem), or write next to it that you are not suppose to fill it in.

Also prevent registration from non-local referrers should also reduce the amount of bot registrations.

There is also the twobox captcha. Where you have one set of instructions for two text boxes, that have a value already set. You tell the user to change the value of one, but not the other (usually something simple). This requires usually a custom bot to attack the site, since such a captcha is beyond the normal (which generally only attack standard captcha implementations, such as recaptcha).