[support] Question on keeping the bad guys out

Wed Feb 5 00:51:59 UTC 2014

Wow. I want to thank everyone for their quick and extensive replies. I will
look at botcha and Honeypot and see if they help. I have the math captcha
on another drupal site but that hasn't stemmed the tide. These replies have
given me enough to keep me bust for a while.

On Tue, Feb 4, 2014 at 6:58 PM, Neil Adair <neiltadair at gmail.com> wrote:

> 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/ ]
>>
>
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>

-- 
John J. Boris, Sr.
Online Services
www.onlinesvc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20140204/ff4b71dc/attachment-0001.html 