[support] Question on keeping the bad guys out

Tue Feb 4 23:58:28 UTC 2014

I use honeypot on all sites and it does a pretty good job, not perfect.
I've also been surprised how well the mathematical CAPTCHA works (an option
in CAPTCHA module) , it's easier for users and it seems the bots can't deal
with it as easily as they do the regular image CAPTCHA probably because
they don't encounter it much. I've also used
https://drupal.org/project/user_restrictions to block repeated account
registrations from some domains.

Neil

On 4 February 2014 17:17, MBR <mbr at arlsoft.com> wrote:

>  THE PROBLEM:
>
> I've helped a number of people whose sites have this problem.  It seems
> that CAPTCHA ("*C*ompletely *A*utomated *P*ublic Turing test<http://en.wikipedia.org/wiki/Turing_test>to tell
> *C*omputers and *H*umans *A*part") has been broken by the black hats.
> CAPTCHA asks the submitter of a form to demonstrate that he can perform a
> task that a computer is assumed to be unable to do.  Google "CAPTCHA
> broken" and you'll find lots of articles.  OCR (optical character
> recognition) software has been around for decades.  CAPTCHA's distort the
> letters in the hope of making the OCR software's task more difficult.
>
> But the black hats don't even need to do that.
> http://www.theguardian.com/technology/2008/aug/28/internet.captcha
> explains that the most successful CAPTCHA-breaking schemes involve social
> engineering.  When the program that's trying to convince your website that
> it's human receives a CAPTCHA image to solve, it can pass it on to real
> humans to solve, and then send their solution back to your website.  There
> are even business models where the bad guys pay people in third-world
> countries a small amount of money to do this.
>
> TEMPORARY SOLUTION:
>
> So, what's the answer.  For the moment, the most effective approaches I
> know of involve a kind of inverted Turing test.  Instead of asking the
> human to prove he's not malware, trick the malware into demonstrating it's
> not human.  One way to do this is to note how quickly responses come back.
> If they come back faster than a human could type them, then they're being
> sent by a machine.  Another way is to insert extra <input> tags into your
> forms and use CSS to hide them.  They won't be displayed by the browser, so
> a human won't fill those fields in.  But a piece of software pretending to
> be a browser operated by a human usually isn't coded to fetch the CSS and
> figure out which fields it shouldn't fill in.  So it will fill in all the
> fields in the form, and the software on your server can then tell that the
> submission is not from a human.
>
> Of course, with a little work the malware can be made to handle both of
> these tests.  You wouldn't even have to write the code to fetch the CSS and
> figure out whether an input field is visible.  It already exists in every
> browser.  You'd just have to lift the right sections of the code from a
> browser, and maybe convert it into a different programming language.  As
> for timing, it's trivial to introduce a random delay before the malware
> sends its response.
>
> So, these tests probably won't work for very long.
>
> TEMPORARY SOLUTION FOR DRUPAL SITES:
>
> When I went looking for Drupal modules that implement these approach, I
> found Botcha, Honeypot, Spamicide, and Spambot.  Initially I tried Botcha
> but it was a struggle to get it installed, and then it didn't seem to work
> properly.  I then looked more closely at the statistics for each of the
> modules I was considering.  I found that Botcha and Spamicide had critical
> bugs that had gone unfixed for a couple of months - not a good sign.
> Especially since the reported bug in Spamicide bug was that on installation
> it wiped the default/files directory.  Spambot showed as unmaintained.
>
> That left Honeypot, which impements both the timing test and the invisible
> input field test.  It didn't have any bugs of severity "Critical", but did
> have one whose severity was "Major".  So I read the bug report on that.  It
> didn't sound like anything that would destroy data or stop the website from
> functioning.  So that seemed like the best solution.
>
> Immediately after I installed the Honeypot module, the bogus registrations
> dropped from about 10 to 15 per hour to about 4 per day.  So, it seems to
> be the best available solution for now.  But I fully expect the bad guys to
> improve their software in the near future to get around these tests.  When
> that happens, we'll be back to square one.
>
> Mark Rosenthal
>
>
> On 2/4/2014 2:22 PM, john boris wrote:
>
> I am working on a new site (Drupal 7) and I have reCaptcha module
> installed which includes the image captcha as well. This still isn't
> keeping out the gnats trying to get logins. I have the site set that all
> new users need to verified with a valid email and the admin needs to
> authorize the new user but it still hasn't stopped them. I am looking for
> other ideas where I can limit these issues. I am getting about 15 a day and
> they seem to be growing.
> I have a few mandatory fields setup but I don't want to make it totally a
> pain for new users to put in the valid info.
>
>  This might be just a cost of having the thing open for new users but if
> anyone can give me some other ideas on how to stem the tide I would
> appreciate it.
>
>  Thanks in advance.
>
>  --
> John J. Boris, Sr.
> Online Services
> www.onlinesvc.com
>
>
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20140204/92a4d2cd/attachment.html 