<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
THE PROBLEM:<br>
<br>
I've helped a number of people whose sites have this problem. It
seems that CAPTCHA ("<span class="st"><u>C</u>ompletely <u>A</u>utomated
<u>P</u>ublic <a href="http://en.wikipedia.org/wiki/Turing_test">Turing
test</a> to tell <u>C</u>omputers and <u>H</u>umans <u>A</u>part"</span>)
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.<br>
<br>
But the black hats don't even need to do that. <a
href="http://www.theguardian.com/technology/2008/aug/28/internet.captcha">http://www.theguardian.com/technology/2008/aug/28/internet.captcha</a>
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.<br>
<br>
TEMPORARY SOLUTION:<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, these tests probably won't work for very long.<br>
<br>
TEMPORARY SOLUTION FOR DRUPAL SITES:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<blockquote>Mark Rosenthal<br>
</blockquote>
<br>
<div class="moz-cite-prefix">On 2/4/2014 2:22 PM, john boris wrote:<br>
</div>
<blockquote
cite="mid:CAOk1TCyZuFjGT_hkrR2X8zvV29Q77tiY1jQAk4Nk6d81d=n+XA@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div>
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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks in advance.<br clear="all">
<div><br>
</div>
-- <br>
John J. Boris, Sr.
<div>Online Services</div>
<div><a moz-do-not-send="true" href="http://www.onlinesvc.com"
target="_blank">www.onlinesvc.com</a></div>
</div>
</div>
<br>
</blockquote>
<br>
</body>
</html>