My forum has been getting hammered by 'registration bots' lately. For technical/logistical reasons, I cannot use captcha. I do use email validation, but there are probably a dozen or so "membership applications" (AKA 'registrations') per day. What's a guy to do???
I decided to try a novel (?) approach. I REVERSED the buttons on the policy page... you know, the ones that say 'Accept' and 'Cancel'. The first paragraph states that the Applicant *must* click the 'Cancel' button. Since my assumption is that bots don't read, I figured I would try this approach.
It is too soon to draw any conclusions, but ZERO bot registrations in past 24 hours! I will keep you posted. Even if it works, it may be only a matter of time until my 'hook' is rendered useless... but I *am* enjoying no bogus 'applicants' for a while.
gary b
<

That's an imaginative trick .

Have you tried forcing the registrants to fill in the birth date, using Shaggy's code?<

Eh...Gary, you do know that most real people also don't actually read buttons?
Perhaps it's better to rename the text on the button from 'Accept' to 'Yup, I agree', and from 'Cancel' to 'Heck no!'. <

Has the added bonus of ensuring peoples actually read the terms
<

Another 18 hours and all is well!! No bot registrations as of yet! Whoopie!
And no... I did not try the birth date thingy.
<

We should start a pool on how long it takes for the bots to figure it out. <

In order to keep bots out all you really need is to require one unique thing at registration time. If they figure it out you just change it.<

That is an interesting point that I too wondered about. *IF* the activity (success/failure rate) of the bots is monitored, then it becomes more likely that bots will be modified to sidestep the change. But based on the 'automated' nature of the bots and the sheer volume of their actions, I'm betting my little piece of cyberspace will get lost in the numbers.
My goal was to concoct something that bypasses email validation if the test fails. So far, so good!!
And Podge... it took me less code (AKA 'pain') to change the button function than anything requiring User input. I'm still betting that this is not likely to be found... unless the bot writers read this topic! <

It must be monitored... three months after I added Shaggy's birthday code (and a few other things) to the church website I'm back to getting bogus registrations like before (and like you mentioned). While they're not getting through due to the e-mail validation, I'd still like to not have to worry about it any more.
I think the next step is going to be a random, hidden, mandatory field....<

Let's see if I can beat Shaggy's 90 day record...
48 hours -- no bots!
[^]<

The GateKeeper mod has worked well since I installed about a month ago. Zero fake registrations so far. <

So you know the last time I posted a suggested fix I never got a bot since then that the fix would have blocked. The bot makers lurk on here finding our solutions and then find a way to circumvent them.<

Of course they do. How else do you think they are going to "reach" the thousands of Snitz users? <

If everyone makes the same field required (in this case, birthdate) on their forums then the bots are eventually going to get rewritten to provide a birthdate at registration as it benefits them to do so. However, if every forum requires one additional field at registration (even better if it's a custom field) then the benefits of rewriting the bots are reduced as each rewrite will only give them access to a small handful of forums again. Pick a field that your members won't mind filling out and that may actually be useful to interaction on your forums (for example, on a weddings site, make marital status required; on a music forum, create a favourite song field and make it required; and son on). Of course, the best way to avoid the bots is to simply create your own, customised registration form - Woo.ie uses this solution and we've had absolutely no automated registrations in over 3 years. Of course, no one solution is going to prevent the manual spammers from registering, but they're usually pretty easy to spot.
<

Of course, no one solution is going to prevent the manual spammers from registering...

Agreed, Shaggy.

Perhaps we should keep less-technical Snitz users in mind. Given a couple years, I could probably come up with the 'custom registration page' you speak of. There may be some (many?) that would not even attempt such a task. This sounds like a MOD is needed. Any 'Snitz coders' up to the task -- a 'custom registration' MOD?? On the larger scale, should this feature be built into the Snitz 'package'?
I am willing to help, but I am better modifying code than writing original code.
<

pardon my ignorance, but how can you build a 'custom reg screen' into the Snitz package, surely it would no longer be custom any more.<

I think the suggestion is to build an admin interface for the registration whereby the admin can specify with each field whether it's required or not.
At least that is the way I am interpreting it. Correct me if I am wrong, gary.<

I am pretty sure that there is already a MOD which does that, it was written by JJenson I think<

Originally posted by HuwR
pardon my ignorance, but how can you build a 'custom reg screen' into the Snitz package, surely it would no longer be custom any more.

Obviously, my wording (or my thinking!) was not clear.

Assume that Snitz setup allowed (requires?) the Admin to specify a field name... any name! This field would then be part of the Registration page/process. User must enter a value (Ex: seven characters starting with current year -- 2007xxx) or a value specified in the Registration instructions. The value entered (upon 'Submit') is tested for acceptance. If the value passes the test, the Registration process is continued.

All of the bogus bot registrations I have seen use the same first and last names (RealName MOD installed). 'Applicant' enters last name in field, clicks Submit, and the value is compared to value entered for first name. If they match, speakers issue a loud flatulence sound!

Use of an arbitrary field name 'randomizes' each forum. If we consider requiring one of the 'standard' User profile fields (such as birth date), the randomness is lost. Bots could be programmed to try each standard field until the correct 'required' element is found.
Again, I would not limit the process to the standard, well-known fields.
I hope this is a better explanation...
[Edit] My apologies... by the time I responded, Huwr had already made his post. If this has already been done, sorry to take up the bandwidth. I (and perhaps others) was not aware of this MOD.<

What JJenson did was to allow the admin to define which fields should be mandatory.<

Sounds like you're after the Podge's Gatekeeper mod.
<

Gatekeeper - http://www.snitzbitz.com/mods/details.asp?Version=All&mid=231

I hope to update it over the Holidays for the latest version of Snitz.<

gary_b,

we use some of the methods you suggest here, firstname is compared to lastname and rejected if the same, also in our register.asp there is a randomly created hidden form field which prevents bots using offsite forms from being able to post registrations. If you do a view source on the registration page and search for hidden, you will find something like this <input name="1KZQK2" type="hidden" value="1MDRM"> (obviously for security reasons I can't divulge exactly how this works )<

Originally posted by HuwR
gary_b,

we use some of the methods you suggest here, firstname is compared to lastname and rejected if the same, also in our register.asp there is a randomly created hidden form field which prevents bots using offsite forms from being able to post registrations. If you do a view source on the registration page and search for hidden, you will find something like this <input name="1KZQK2" type="hidden" value="1MDRM"> (obviously for security reasons I can't divulge exactly how this works )

Why doesn't this get added to the base code? If it is something that is randomly generated, I don't see why putting it in the base code would help the spammers.<

I'm slightly puzzled - bots don't press a button on a screen normally, but just play out a rehearsed script, so if the submit and reset buttons just changed position, how would this stop the registration? The form submission is still a submission?!<

- bots don't press a button on a screen normally, but just play out a rehearsed script, so if the submit and reset buttons just changed position, how would this stop the registration? The form submission is still a submission?!

Well... I don't want to give the appearance of knowing what I am doing! But this is my thinking... and it has worked so far! NO bot registrations for days!
The bots work off a script. That script 'looks for' a submit button on the page. (By looking at 'page source'??) Upon finding a button labeled 'Submit' or "Accept", it 'calls' that button's link or action. *My* "Accept" button is tied to redirect back to main forum page. [Insert giant raspberry sound for bots!] In order to defeat button reversal, the bot script would have to 'analyze' the link/actions tied to the buttons.
Sound like a bunch of arm-waving and mumble-jumble?? Well, it is. But that's the best explanation I can give for my logic.

Refer to first paragraph -- last sentence. <

Received today from forum owner...

Got first app since you killed the bots... Steve
sherm@xxxx.com wrote:

This technique is working. Which leads me to imagine a variation that would be unique to each forum:

What If... the policy page was changed to use one specific word in the text (selected by each Admin for their forum) as the "Accept button". Displayed button would be a dummy -- AKA 'honey pot'. This sure would 'randomize' the population of Snitz forums.<

Originally posted by gary b Sound like a bunch of arm-waving and mumble-jumble?? Well, it is. But that's the best explanation I can give for my logic.

Result! I have to be honest, I'm not sure why that would work, as the form submission is unlikely to involve the bot 'looking at' anything, just calling the URL's with paramaterised querystrings. If the only thing to have changed is the button position, that ought not affect it (although if the button has changed name, it might, and will depend page by page)

I'm not saying your solution can't work (I'm very happy that it does), just puzzled why it works!<

FWIW... the button positions and names have not changed. But the code that drives the functionality of each button has been swapped with the 'other' button. Can't get much simpler than that.
Four or five days now and no bots -- nada! zilch! squat!!
<

Will you post the chunk of code so we can all see this and apply this to our forums? I think I understand what you are saying but would love to see it to make sure.<

No problem, JJ...
RIGHT-click link below
'Save Target/Link As' to your desktop
Open in NOTEPAD with word wrap turned OFF
Actual code changes involve only about 4 or 5 lines. I did change narrative (my lines 57-63) to provide instructions about how to Register. Note spaces I used in my instructions to spell word:
c a n c e l

[Link not available]
Make backup copy of policy.asp BEFORE trying this change!
Questions?? Let me know...
gary b

[Edit: right-click instructions]<

Very simple and nice. That would definantly screw me up the first couple times cause I usually don't read the policy on forums <

Code changes implemented: Dec 18
Today's date: Jan 10
Number of days: 23

Number of bogus bot registrations: ZERO!
Anyone else try this? If so, with what results?? <

That's great news gary b :-) Anything that stops/slows up these filth is good for us all!<

I will try and implement something like this at some point I just made a switch in hosts and have more pressing needs than the forums. But I think I am doing a site for my HOA and I think I will implement this to and hope it has the same results.
<

6-month report:

ZERO bogus bot registrations!! NADA! ZILCH!!
Number of Applicants that did NOT need registration assistance: 20

Number of Applicants that needed assistance to register: 1

<