Reverse CAPTCHA ~ Thoughts, Tips, and Questions

[Russ Edwards]

…

Hi Teccet –

Your 1px method is one of many that should work as Reverse CAPTCHA.

You might want to try copying your form (at least the 1px area) and see how it pastes. That will give a different “view” of the form.

To avoid your honeypot field from being selected if someone tabs through the fields, set tabindex="0" and that will take that field out of the tab sequence.

The good news is that unless your site becomes seriously worthy of a spammer’s full attention, it is doubtful that they will target an implementation or Reverse CAPTCHA based upon the bot employing an algorithm that finds the fields being made invisible on the screen and avoiding them. The reason is because there are so many ways to make them invisible using CSS, and even if we all used the same way, our field names would all be different as would be the class names containing the magic invisible dust. With external style sheets in use, they would also have to parse those to see what was what. It just wouldn’t be worth it when there is so much lower hanging fruit.

Good luck!

Russ . . .

…

[Russ Edwards]

…

Hello –

I've posted the following in the original thread where I discussed my original reCAPTCHA problem, but thought it a good idea to repeat it here as it details what can go wrong with an implementation of reCAPTCHA on FM that is a hosting issue rather than an FM or reCAPTCHA issue.

To recap, my implementation of reCAPTCHA on FM on my various forms on websites hosted at Go Daddy had been working for some time, then suddenly stopped working, then about a week later started working again, all without any change to my forms, html, or php files.

I concluded it must be something on GD’s end, I contacted them, and after some checking they told me it was nothing on their end.

Finding no solution, I started switching my forms to Reverse CAPTCHA after some research.

Since the forms were working again I wasn’t as pressed to reconfigure all the forms, so I left many of them as they were.

I had also noticed a correlation between whether reCAPTCHA was working or not, and whether Filezilla (my FTP app) was able to connect on the first try or not.

Yesterday Filezilla took two tries to login again, for the first time in a week. I immediately tried a form I hadn’t reconfigured yet and sure enough, reCAPTCHA failed again, too.

I immediately called GD again and was more insistent they find a cure. The case was escalated to a “Hosting Specialist” or some such who immediately recognized what was going on when he heard that Filezilla was taking two tries to get in.

This is my understanding of what he was trying to tell me:

My hosting account is on a shared Linux server, along with hundreds (maybe thousands) of other websites, all of which share the same ip.

For security they have a “filter” (his words) that is applied from time to time on different accounts (presumably at random) to insure all those sites get a fair amount of bandwidth.

Evidently accounts hosted on GD get hit more than 3 million times a day with one attack or another.

When that filter is on it stops certain access attempts. It presumes legit attempts will try a second time and bogus attempts will not. That is why Filezilla is successful on the second attempt, which by default it is programmed to try a few seconds after the first attempt fails.

Again, hearing that caused the tech to recognize what was going on.

However, Google only tries once to validate the reCAPTCHA submission. Since the first (and only) attempt fails, Google returns a validation failure and that is why (according to GD) I was having the issue with failing reCAPTCHA authorizations.

The intermittent failures are due to that filter being applied or not.

Their solution was for me to do one or both of the following:

1. Buy a static IP for my account at $5.99 a month. Accounts with “fixed” ip address are not subject to filtering, since it is unlikely I would try to harm my own account and wouldn’t need filtering protection from myself.

2. Have my account migrated to their new 4GH (Fourth Generation Hosting) service at no cost. There are some things 4GH doesn’t do that their old shared hosting did do, but it is far more robust and scalable. And the likelihood of suffering that filtering thing is somewhat less.

I chose 2 for now, and will consider a static IP, or upgrading to the next level of hosting which includes a static IP, if I continue to have this problem. This, presuming I stay with GD.

Now, I am not a hosting expert, so I have no idea if their story is valid or BS. Since migrating to 4GG, however, Filezilla logs in on the first attempt and reCAPTCHA works. That could change tomorrow.

I am not necessarily a big fan of GD. I do seem to get the most bang for the buck there, and their support is US based and there is almost never a wait when I call. I have had very few issues over the years and all questions have been adequately answered on the first call.

Their website is a nightmare and you can’t buy anything without navigating through screens and screens of upsells, most of which are not necessary.

But I have no loyalty to GD and if a better deal came along making it worth my time to move a couple dozen websites and domain names, I wouldn’t hesitate. But unlimited hosting for unlimited domains for usually under $6 USD a month is hard to beat. Their 4GH hosting, if in reality is even close to their hype, is about as state of the art as shared hosting can be. My sites were fast before, but feel even faster now after migrating to 4GH.

My point here, in hopes that it might help someone else, is that I have now confirmed the reCAPTCHA failure was 100% on Go Daddy’s end, and had nothing to do with FormMail or reCAPTCHA.

To implement reCAPTCHA, follow the instructions *exactly* as given on the Tectite site. It does work – flawlessly. If it doesn’t work, call your webhost.

Good luck…

Russ . . .

…

[teccet10]

…

You might want to try copying your form (at least the 1px area) and see how it pastes. That will give a different “view” of the form.

To avoid your honeypot field from being selected if someone tabs through the fields, set tabindex="0" and that will take that field out of the tab sequence.
…

Good thinking on both of those.
I copy and pasted and nothing showed up. Of course I didn't label the field with any text so no text showed up.

[tomdkat]

This thread has been a great read, even though I've mostly skimmed it at this point. When I'm ready to give reverse CAPTCHA a try, I'll come back to this thread.

One comment I did have to make is regarding the use of the "display:none" property and the effect it can have on SEO. I think some search engines "frown" upon hiding content from users that robots, spiders, and crawlers can "see". I don't know if doing using "display:none" on a HTML form will have any adverse or otherwise negative effects on SEO but I wanted to mention it anyway.

Thanks for the great thread!

Peace...

[tomdkat]

This thread has been a great read, even though I've mostly skimmed it at this point. When I'm ready to give reverse CAPTCHA a try, I'll come back to this thread.

One comment I did have to make is regarding the use of the "display:none" property and the effect it can have on SEO. I think some search engines "frown" upon hiding content from users that robots, spiders, and crawlers can "see". I don't know if doing using "display:none" on a HTML form will have any adverse or otherwise negative effects on SEO but I wanted to mention it anyway.

Thanks for the great thread!

Peace...

Ok, so I now have reverse CAPTCHA implemented on my contact form. We'll see how it goes. Right now, I only have two fields defined, per the instructions I followed, and I might add more later.

Thanks again!

Peace...

[teccet10]

Well that didn't take long.

Here we are only 5 months later and I'm starting to get a lot of spam submissions.

The reverse captcha isn't doing the job.

[russellr]

Hi,

Is your site one that a spammer would spend time targeting?

I recommend you analyse what's in the spam to see if other techniques will help, such as URL detection.

Also, with our Reverse Captcha, you can always add in another field or two (must be empty, must not empty) and that will mean the spammer has to re-evaluate and do more work to overcome it.

The other thing is to check that you're not making the R.C. too obvious, and also you can move the new fields to a different part of the HTML page, so they are not all in the one place.

And use a different technique for hiding these new fields.

There're many things you can do, you just have to think like a spammer to beat them.

If you need assistance with this, we do offer subscription based support.

[teccet10]

I will try those things.
To tell you the truth, while there's a lot of them coming through now, I have noticed a pattern.

Where it asks for a phone number, they're all putting "123456".

So I'm wondering the best way to specify that the phone number needs to have at least 8 or 9 characters including dashes.

Can't use URL detection because legitimate users often have URLs.

[russellr]

Hi,

OK, for your next Reverse Captcha field, called it "other_phone", or something like that, and specify it must be blank. (Provided you don't have a field called that, of course.)

And put that field near your current phone number field.

[teccet10]

I'll give that a try as there are already two phone number fields and they enter 123456 for both.
But is there any way to require a certain number of chars?