My Honey Pot's in Trouble - Can you help?

Hello. I'm running Evolution with eForm and have successfully combatted form bot spam for a year and a half now. I had hidden the Honey Pot field with CSS using Display: None;

Recently one or more spam bots showed up with the smarts to find the CSS hiding the Honey Pot. I just changed the method of Hiding to "Off Screen" using { position: absolute; top: -999999em; left: auto; width: 1px; height: 1px; overflow:hidden;} This, surprisingly, didn't help a bit. As I said, I'm dealing with smarter spam bots.

I'm looking for some advice as to how to proceed. For example. might I benefit using Javscript to hide the Honey Pot. OR, have we reached a point where we have to employ interactive questions like 3+4 or is a volcano hot or cold? I'd like to know what to try next.

I also have a somewhat related question. I know enough about the form bots to know that once they're successful at a given website, they no longer need to use the form. They know field names, how the honey pot is hidden, where to send the form for processing, etc. Correct me if I'm wrong, but even if I make certain changes to the honey pot, a bot that visited previously can avoid my revised form and continue to defeat it ... at least that is unless I make additional and smarter changes.

Can someone give me guidance, preferably in the eForm arena, as to what parametes I need to change to stop all previous form bots in their tracks. Example, do I need to change all the form field names, the action statement, and so on. Unfortunately I don't have a clue what I need to do.

To summarize, I need advice on 1) how to rescue my current Honey Pot and change it in some way(s) that will defeat the bot, such as possibly Javascript, and 2) what changes are necessary in my present form syntax to stop previous successful bots from bypassing the form.

I'm all ears. Thanks very much ... Sam [ed. note: samg last edited this post 12 years, 8 months ago.]

Have you tried changing the name of the Honey Pot field?

You might also be able to hide the form if it is a known spammer.

https://www.revitalagency.com/blog/hide-form-if-ip-is-a-spammer/

Try changing it to first_name.

http://cristersmedia.com/eliminate-spam-in-modx-eform-without-captcha

I can't say this is 100% spam proof, but it's interesting and I've used it on a number of client sites in the past year that I don't seem to get calls about spam coming in through their contact forms.

Also, since implementing it on my own form I get anywhere between 1 and 4 spam emails a month. Not too bad considering it was more like 10 a day prior to that.

Quote from: bwente at Feb 17, 2014, 04:45 PM

Have you tried changing the name of the Honey Pot field?

You might also be able to hide the form if it is a known spammer.

https://www.revitalagency.com/blog/hide-form-if-ip-is-a-spammer/

bwente, actually I changed it yesterday but I wasn't sure it would help. The reason I changed its name was in case previously successful bots were avoiding my form at this point, then when eForm parsed their input stream it would find a field missing and perhaps reject the request on that basis alone. Those bots would have to go back to filling out the form to see that there's a new Honey Pot field to deal with. Maybe this would buy me some time with those bots. Also, I just changed the CSS for the Honey Pot to "offscreen". Perhaps they're smart enough to deal with "display: none" but not the offscreen approach.

I hope everything I just said makes sense to you. Do you think that my logic is sound for changing the name of the Honey Pot field, and is that why you suggested it?

Thanks ... Sam

Quote from: BobRay at Feb 17, 2014, 05:07 PM

Try changing it to first_name.

BobRay, why did you suggest that particular string? Are you thinking that a smart bot would be more tempted to submit data to a field that appears as important as the requestor's name?

I did call it 'Country' for this reason but I realize that's not as important as the person's name.

Thanks for your response ... Sam

Quote from: frogabog at Feb 18, 2014, 02:03 AM

http://cristersmedia.com/eliminate-spam-in-modx-eform-without-captcha

I can't say this is 100% spam proof, but it's interesting and I've used it on a number of client sites in the past year that I don't seem to get calls about spam coming in through their contact forms.

Also, since implementing it on my own form I get anywhere between 1 and 4 spam emails a month. Not too bad considering it was more like 10 a day prior to that.

frogabog, believe it or not I found your referenced implementation in Google and had recently tried it but the bot eluded it the next day. If I'm misunderstanding why can you please set me straight?

That solution requires that the Honey Pot field be a date field and then rejecting the submission because it's not a date. I tried that but since the field must be optional the author of the form bot simply avoids entering the field, just as he would with the conventional Honey Pot. Now there's no field and therefore no datatype error.

What have I missed? ... Sam

I wonder if part of your problem is that there's an indication to the user that tells them whether the form was accepted. That allows smart bots to keep trying various strategies until something works.

BTW, if you look at the code of SPForm, you'll see options for requiring mouse or keyboard action, and an adjustable time window the user must spend looking at the form before submitting it. Many bots either submit the form instantly or have a long delay between the request and the submission.

If you really need to eliminate spam, though, using the MODX CAPTCHA extra with the 'mathstring' option is completely spam proof in my experience. With a little effort, it will work with any form. You could also modify it so that it doesn't show for certain users, though that would be more tricky.

Probably haven't missed anything. Maybe rename the field "retype email" or something like that.

Quote from: BobRay at Feb 18, 2014, 10:50 AM

I wonder if part of your problem is that there's an indication to the user that tells them whether the form was accepted. That allows smart bots to keep trying various strategies until something works.

BTW, if you look at the code of SPForm, you'll see options for requiring mouse or keyboard action, and an adjustable time window the user must spend looking at the form before submitting it. Many bots either submit the form instantly or have a long delay between the request and the submission.

If you really need to eliminate spam, though, using the MODX CAPTCHA extra with the 'mathstring' option is completely spam proof in my experience. With a little effort, it will work with any form. You could also modify it so that it doesn't show for certain users, though that would be more tricky.

BobRay you didn't answer my question about why you recommended FIRST_NAME. Was my assumption correct?

As for an indication to the user that the form was accepted, yes there's a message that goes back to the area of the screen where the form WAS. I think that's a default and regardless, I don't think a bot could understand it unless it waits around and looks for words like success to be returned.

I'm not talented installing MODx. I inherited the installation and have sufficient skills to make changes and solve many problems but I prefer not to install SPForm.

As for using CAPTCHA, I don't like that device. It bothers me as a user of the internet to deal with this contrivance. It's often impossible and at best annoying. I do have another web site I manage that uses MODx with CAPTCHA and bots have defeated it somewhat easily with legible fonts like arial and courier. I've had to change the fonts to ones that imitate handwriting to improve the protection.

Here's a question for you. Is the weak link in the normal Honey Pot implementation using CSS to hide the Honey Pot? It seems so. Do I have a better chance using Javascript to hide it?

I've had terrific success protecting forms on non-CMS sites by using Javascript. The technique involves using JS to replace the ACTION parameter of <FORM> with the correct name of the processing CGI script, whereas the original script specified doesn't exist. The second thing the JS does is enabling the SUBMIT input statement which otherwise looks like

I wonder if I could superimpose these two techniques upon eForm. Apparently form bots don't understand JS and haven't for years. I don't understand why but my forms that use JS haven't been the victims of SPAM for several years. Do you think this use of JS will work for me here?

Thanks ... Sam