XF 1.1 1.1.4: Anti-Spam Improvements for Registration

1.1.4 includes some additional anti-spam options for the registration form. These are small enough improvements that they can be done for a 1.1.x release. You will see some deeper integration of additional tools (such as the previously-shown StopForumSpam) in 1.2. As always, targeted attacks may potentially be able to mitigate some anti-spam techniques.

Built-in Registration Timer
A registration timer system is now built-in to the registration form. For a valid user, they simply cannot submit the form until the time is up. If a person submits the form without waiting long enough, they will need to wait again until to submit the registration.

This can be configured in the admin control panel:

Unique Registration Key
This ensures that the registration form must be displayed before any registration can take place, making more work for bots. Each key can only be used once. (This is not a particularly strong protection on its own, but every little bit helps.)

Integration with DNSBLs
There are several DNS Blackhole Lists (DNSBLs) that track spam or malicious IPs (Spamhaus and Tornevall, in particular). These can be queried on registration and if the requesting IP address is found on them, an action can be taken.

In case you're wondering, we've made it much easier to see if there are users pending admin approval as well:

Expect more in the future...

 

[EgyKit]

Unique Registration Key
This ensures that the registration form must be displayed before any registration can take place, making more work for bots. Each key can only be used once. (This is not a particularly strong protection on its own, but every little bit helps.)

This will be very helpful I already use my custom add-on to send random verification code based on the registering IP address and email address and it really work and help in preventing spam registration. this was a must feature for me before I decided to move from vBulletin to xenforo and it took a lot of work to get it working correctly and integrated with the verification fields before registration complete

You can see it live here after email field in the registration form:

http://www.egykit.com/misc/language?language_id=1&redirect=/register/

Thank you Mike.

 

[Crayo]

The registration timer is fantastic. Not sure why I never thought of something this simple but so effective. Good job.

 

[SeaDog]

That would potentially confuse people signing up as they wouldn't understand why the Sign Up button was greyed out.

No you misunderstand. You don't grey out or disable the button, the script simply works out the difference between the page being shown and the form being submitted. No real (non-bot) user can complete the form and submit it within, say, 3 seconds. If the time difference is < 3 you flag up a warning (and/or ban the registration). We have this working nicely (as a custom mod) on an IPB forum I run. Just thought I'd chip in my 2 cents on an alternative as I think it's nice to keep things like timers, which will only apply to bot users, hidden from the public facing page. Maybe @Mike and team will consider this - it's basically the same idea, but without the need to show anything to the users.

Not sure why I never thought of something this simple but so effective.

If it makes you feel better, then some of us already did and implemented this with great success - glad to see it's coming to XF too, although I'd prefer the hidden timer personally

 

[Crayo]

If it makes you feel better, then some of us already did and implemented this with great success

Makes me feel worse .

 

[Bubka3]

The registration timer is fantastic. Not sure why I never thought of something this simple but so effective. Good job.

My question is, won't they make the bots wait after we start using this?

 

[Deepmartini]

That's it ... you've cracked it.

The Registration Form Timer is one of the most effective solutions to the problem as demonstrated by the implementation of it in my add-on and XenUtiles and FoolBotHoneyPot.

Bye bye spammers

Can people still use these addons or will they interfere with this new feature?

 

[Chris D]

Not really sure how the registration timers will interact with each other but the key there is to just disable the ones you don't want to function. So you could disable the 1.1.4 timer that's built in if you already use reg form timer for the stop botters integration etc

 

[sonnb]

This update is going to override 1 function of my Spam addon but it awesome for everyone

 

[kkm323]

i don't see how this will help reduce the spam, it will creates more problem for the common users

 

[aculate]

Love the "Users awaiting approval" in the admin bar. It was a pain having to go into the admin panel to check, especially with all the bots.

same here... love this new feature

 

[Crayo]

My question is, won't they make the bots wait after we start using this?

Bots inevitably adapt and overcome in time, but it's a great method to halt them in the present.

 

[tyteen4a03]

Bots inevitably adapt and overcome in time, but it's a great method to halt them in the present.

I think they have already adapted. Registration forms timers are implemented in a lot of forums.

I would like to see randomized class names and layouts (I prefer to call them HTML mutations) so to confuse the bots.

 

[Anthony Parsons]

This is one area I believe should be core, as core forum on the www equals spam haven. This simply should not be left open to developers to close registration spam.

Please take a look at some of the solutions now offered, such as image type captcha integration, from KeyCaptcha or any other provider, as default options. Also to extend the registration timer principle to incorporating the foolbothoneypot type structure, incorporating random hidden fields that are only viewable to bots, so if filled, the registration fails.

Spam protection is core XF, and this really needs work with what is now available to beat / remove spambot issues.

I would also like to see default link limits imposed in XF, which stops new members using anywhere for a defined set limit by the admin, PC's, posts, profile fields, etc.

Again... spam protection is one area that IMHO, is Xenforo's responsibility to provide the best available solutions direct to the customer, and not have to use third party products to keep spam at bay.

 

[Boothby]

The sad is, the spam industrie will adapt. This is only one step ahead. But better one step ahead than one step behind.

 

[Case]

When you make things core they eventually get cracked and become useless. I think installing your own combination of anti-spam modifications is always best. Forums become a lot more unique and therefore harder to crack.

 

[tenants]

So... how long before all the bots just request the registration page, then wait 90 seconds before submitting the response?

Yes, that's one of the next moves for spam bots

If you create a weak antibiotic and give it out to a large population for minimal reasons (for instance minor acne), the bacteria becomes more resistance and stronger against any similar antibiotic.
Thus, the problematic rise of super bugs, in retort to this, we must find novel mechanisms and target bacteria in completely new ways.

In a similar way, by using mechanisms that spam bots can adapt to, and using these mechanisms for a large population, we provoke them to become stronger.
In similar fashion, we then need to also look for novel mechanisms and target spam bots in completely new ways.

For this reason, I don't believe it to be great idea to use weak mechanisms that can be bypassed in the core.
However, to be honest, I'm surprised a larger % of spam bots haven't already bypassed the timer mechanism.

The majority that do bypass currently, are just fluke.. they bypass it due to slow proxies or slow hosts. However, adding script pausing to your spam bot is trivial. Script pausing will not slow the bots down, instead 1000 threads will start 20 seconds later... and so will then next 1000... effectively, a million threads, scripting against millions of registration forms have just started 20 seconds later

The timer mechanism has been around for several years, and as any mechanism becomes popular it becomes a target

By putting this mechanism into core, the timer mechanism becomes a larger target... but if this mechanism is bypassed, I don't consider it to be a huge loss (It didn't catch 100% of bots anyway)

I would still caution the use of putting weak anti-bot mechanisms that can be bypassed into the core.

 

[whynot]

By putting this mechanism into core, the timer mechanism becomes a larger target...

Put it as the first step.
Start the timer with the warning to wait for 8 seconds.
Let the user register.
Did the user register in less than 15 seconds?
Reject.

 

[tenants]

Put it as the first step.
Start the timer with the warning to wait for 8 seconds.
Let the user register.
Did the user register in less than 15 seconds?
Reject.

Point your script (targeting 1 million forums) at XenForo forums
Start the session, creating 1000 threads at a time
At the registration form, pause the script for 20(or x) seconds
Did the spam bot register in less than 15 seconds?
Pass

After the spam bot upgrade, did this effect the spam bot?
No

After the spam bot upgrade, do spam bots now bypass all registration timers?
Yes

Is the registration timer now a mechanism that can be used to prevent spam bots?
No

For the longevity of anti-bot mechanisms, is it wise to use weak anti-bot mechanisms in the core for large populations?
if(user_has_thought_about_this?'No':'Yes');

 

[whynot]

Point you script (targeting 1 million forums) at XenForo forums
Start the session, creating 1000 threads at a time
At the registration form, pause the script for 20(or x) seconds
Did the spam bot register in less than 15 seconds?
Pass

Pause for 8 seconds.
Did the user start typing, clicking before the 8 seconds?
Yes? Reject.
No? Stop the clock.
Start the clock again.
Did the user complete the registration in less than 7 seconds?
Yes? Reject.
No? Approve the registration provided confirmation from the email address arrives.

 

[tenants]

You are doing exactly the process that is done in practice, by showing it with theory
By continuing, you are simply describing the arms race, and how each mechanism a long the way can then no longer be used

Every process that you create, I will create an alternative to bypass it

Eventually, you run out of mechanisms or ideas... but that means every mechanism along the way that you have thought of, my bot now bypasses
In effect, you have made my bot incredibly strong, and nobody can use any of your past mechanisms (the anti-b(i)otics have now become ineffective)

-Add mechanism (send request to screen touch/type javascript) after x time
does the bot pass?
Yes

(This is actually a mechanism that was prepared for FoolBotHoneyPot, I was also going to use patterns of keypress/touch... but it's not currently needed. However, the keypress tables are already present in the plugin)