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.

ss-2013-03-11_16-39-03.webp


This can be configured in the admin control panel:

ss-2013-03-11_16-39-57.webp


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.

ss-2013-03-11_16-43-57.webp


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

ss-2013-03-11_16-44-51.webp


Expect more in the future... :)
 
Click to expand...
tenants said:
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)
Click to expand...

Exactly. That's why a layered approach makes sense to me -- apply a series of measures that are very difficult for a machine to circumvent (custom QA, custom image captcha, etc), then if it passes, throw a battery of other things at it just in case something else sticks. Outright ban based on some metrics, hold others for admin review.

Theoretically, there's little/no payoff to the spammers for solving the second-tier problems, because they can't get by the first tier regardless.
 
Mike said:
It's not out yet.
Click to expand...

Mike: Just curious to find out whether you saw my suggestion to make the timer behind the scenes (so script compares time of load vs submit) rather than showing it to users via a button that unlocks? Will have same effect, just one less thing for the users to have to see/worry about!
 
Chris Deeming said:
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 :)
Click to expand...
Will this conflict with any of the existing add ons? Can I uninstall some of the addons once this is active?
 
SeaDog said:
Mike: Just curious to find out whether you saw my suggestion to make the timer behind the scenes (so script compares time of load vs submit) rather than showing it to users via a button that unlocks? Will have same effect, just one less thing for the users to have to see/worry about!
Click to expand...
On the flip side, I prefer it being visible and I wish I had implemented it in my own add-on that incorporates a registration timer.

There are certain cases where a legitimate user may be able to complete the registration form quicker than the time limit.

These cases include a browser auto-complete plugin and more commonly a case whereby a user can make a mistake on the registration form and get an error (maybe typing the wrong password so they don't match). How do you handle this? The next time they come to the form, most of the data is filled in so you can't invisibly set the timer back to 10 seconds as they will complete it in less than 10 seconds. You can't really reduce the timer either because there's no way for the page to know you previously made a mistake (such as if you just use the browser back button).

So, it's very important to put this client side block in place. And there's no harm in doing so.

In the case I mentioned above, if you make a mistake and click back, the timer does indeed reset. But with the visible timer, it is clear to the person registering why this is happening and they'll have to wait.


Rho Delta said:
Will this conflict with any of the existing add ons? Can I uninstall some of the addons once this is active?
Click to expand...
You can safely uninstall other add-ons with registration timers. There's no point in running this functionality more than once. But you need to be aware of what other functionality these add-ons have as they might still be important.
My add-on, Registration Form Timer includes a timer so that part is redundant now. But it also includes a highly effective API called StopBotters. This is actually much more effective at times than the registration timer alone. My advice would be if you wish to continue using that StopBotters API that you should disable the default registration timer.
 
I use a registration timer that is set to a very low value, so that it does not block legitimate users. IMHO its not needed to display a registration timer in such case. It only bothers legitimate users.
It would be nice if displaying the timer would be an option that admins can choose to set.
 
The DNSL integration is a welcome addition, for sure.

Alfa1 said:
I use a registration timer that is set to a very low value, so that it does not block legitimate users. IMHO its not needed to display a registration timer in such case. It only bothers legitimate users.
It would be nice if displaying the timer would be an option that admins can choose to set.
Click to expand...

Good point.

I've never used registration timers, so it'd be interesting to A/B test it and see what the conversion rate is. Time is precious, and unless there's some very compelling reason to register, I know I'd probably hit the back button and move on if I had to sit and wait to press submit.

The best approach is certainly a layered one. We used to check for mouse movement (as soon as the page loads), which would clear a pre-populated field. If the field wasn't empty, bot it is. It worked good, but it certainly wasn't an ideal solution -- a problem for people without js enabled (though not a huge concern for us) or those who don't use their mouse much (e.g., the blind and disabled). We now require verification via phone for suspected spam registrations, but had we stuck with the mouse approach, I definitely would have explored making it more accessible.

For instance, it's rather trivial to check if the browser has emitted any touch start events for mobile devices. Similarly, we could have captured key down events (specifically arrows and tabs) and pare down the false positive from people using other accessibility devices / browsers.
 
Not to be a pain, but a question in general.

I know that we have a normal QnA captcha but like the ability to run something else with it? Like a side by side or w/e you would call. IPS offers something like this, where you can set up a QnA but also have reCaptcha running with it.

Would it be too much for you guys to implement in 1.1.4 or would you even consider adding a feature like this possibly in the future?
 
Cant wait for the upgrade!!!It really saves time and resouces on those extra add-ons for spam mitigation!Xenforo always getting better and better!XenForo=Awesome always!
 
I have just purchased XenForo and love it. I joined the community here last year, and while I have been mostly reading forum posts I can honestly say that I am very impressed how good the support is. I am looking forward to working with 1.1.4 and I will post a link to our own forum once it's ready :-)
 
Back
Top Bottom