34 comments

[ 3.4 ms ] story [ 97.0 ms ] thread
OK, I like the idea to use a "hidden" captcha to block automated spam bots. However, I don't think a hidden blank field is enough.

Maybe you could use javascript to set a value in that hidden field. Or make sure the client loaded the empty form page first?

Anyone have better tests?

remember that spam bots can be designed to work just like a browser and so they can execute javascript too.
For any programmatic way of checking to see if the user is a human, without them interacting with the system, there's a programmatic way of faking it.
If you not only block problematic comment, but also block abusing IP address from for next couple of months -- it would be pretty hard to figure out what exactly your anti-abuse system checks for. Especially if your system check for several red flags.
Site is down for me at the moment so I'm not sure I understand what you mean by "hidden blank field" but I have a niche social network with around 150k pageviews/month and a simple css hidden input field on the signup form has been enough to keep all the spam away.
Well, one way is to have a form input hidden by css, that is like spam catching 101.

I actually found a fairly interesting sort of captcha I am using for signing of rental agreements using jsignature which draws a canvas that people can sign using their mouse.

This updates a hidden form element with mouse x/y data to draw the signature again if you need to. You could potentially use something like this, but reCaptcha is incredibly easy to integrate.

Not my list (original source would be welcome, if known):

  /*
   * The types of spammers include: playback bots, form-filling bots, and
   * humans. This script reduces automated form submission from both bot
   * types.
   *
   * CAPTCHA failure: xrumer (http://www.botmasternet.com/) DeCaptcher
   * (http://decaptcher.com/client/), http://allbots.info/, and
   * CAPTCHA bypass (http://www.guruperl.net/products/captcha-bypass/).
   *
   * =======================================================================
   * Playback Bots
   * =======================================================================
   * Playback bots take data that has already been submitted against a form
   * and continue to resubmit it.
   *
   * [X] Weakness: Hash a timestamp, IP address, and browser name within hidden
   * input fields, encrypted with a password.
   *
   * =======================================================================
   * Form-filling Bots
   * =======================================================================
   * These bots mechanically fill in form fields.
   *
   * [X] Weakness: Honeypot fields. Hidden from users using CSS, the input field
   * is not displayed to human users, but shows up for bots. The field should
   * shift its order randomly (relative to the valid fields).
   *
   * [X] Weakness: Misnamed fields. Randomize the names of fields. Record the
   * real names within a hidden input field.
   *
   * =======================================================================
   * Humans
   * =======================================================================
   * There is no way to prevent a human from spamming you. However, you can
   * use JavaScript to make the submit button disabled for a short time.
   * (Like the time it would take a human to fill in all their contact
   * details.)
   *
   * Weakness: Double submissions. Disable the submit button using JavaScript
   * once the user has clicked submit.
   *
   * =======================================================================
   * All Bots
   * =======================================================================
   * [X] Weakness: Timestamp fields. The time between generating the form
   * and submitting the form must be after a minimum number of seconds (5),
   * but no longer than a certain number of minutes. TIMEOUT page.
   *
   * [X] Weakness: Session variable. This ensures that the form was posted
   * from the website, not remotely POSTed. See: session_start(),
   * session_destroy(), and unset.
   *
   * [X] Weakness: Cookie variable. This also ensures that the form was posted
   * from the website, not remotely POSTed. See: session_start(),
   * session_destroy(), and unset.
   *
   * [X] Weakness: Word count. The number of distinct words (characters
   * separated by spaces) must be above a certain count.
   *
   * Weakness: Duplicate data. All form data must be unique.
   *
   * [X] Weakness: HTTP REFERER. When the page is initially loaded, the HTTP
   * REFERER is added as a hidden, encrypted field. The value must be the
   * same as when the form is submitted.
   *
   * [X] Weakness: Email address. The email's doman must have an
   * MX record in a non-bogus IP-space. See: checkdnsrr( doman, "MX" )
   *
   * [X] Weakness: Links. Comments can only have one website link.
   *
   * [X] Weakness: Strip HTML. Comments are stripped of HTML tags.
   *
   * [X] Weakness: Name. The name must contain "typically" valid characters for a
   * person's name. Regex: "/[\^<,\"@\/\{\}\(\)\*\$%\?=>:\|;#]+/i"
   *
   * [X] Weakness: Mollom. http://mollom.crsolutions.be/
   */
They are like 5 seconds of annoyance. I fill them out all the time, and I still don't particularly care. (perhaps because when it's a recaptcha, I am too busy gleefully wondering which word is the test and which is the text)

If I wrote this article, it would go...

Why you should never use CPATCHA:

Because reCAPTCHA exists. You should be using that instead.

That sliding solution is great if you don't care about accessibility, but then I suppose visual-only captchas don't really work very well for the blind, either.

Wonder how it works if you have javascript disabled, or are using a text-only browser, or have NoScript installed.

I've used something like: Please join these two "words" together (without spaces): hitgzwhv and iprmagfg A little copy pasting required, but I discovered an older simple math one was vulnerable. Also changing the comment submission link seemed to have helped on its own.

What I don't believe in is a captcha after the registration process. But in any case, wouldn't the idealized solution be a Bayesian spam filter? Is there an open source well-trained one out there that's easy to bolt onto anything?

..maybe pg knows of a few?
The strength of Bayesian filters is that they tailor to individuals, i.e., everyone can have a different model. An open source "well-trained" one is trivial to subvert.
What he doesn't get is this: Yes, they are easy to crack, especially using crowdsourcing, against which there's no defense. However, that still is a threshold against automated attacks, however small.

The argument is the same as a free product vs. one that costs 2 cents, having a price, however small, changes the category. Or, you can think of it this way: Most simple home locks can be picked in less than 30 seconds, but you still lock your door, although it's a nuisance (find your keyes, etc.), knowing full well that this won't stop a determined attacker.

It is funny that we are still using these old systems in CAPTCHA and reCAPTCHA.

This week, NuCaptcha launched a video captcha offering. They have solved the readability and sweat labor issues that have come about. It's a true security offering that also improves input accuracy to 99%.

http://Nucaptcha.com

Disclosure: I've advised with NuCaptcha on a pro bono basis.

Quick! Someone register "catpchaclassic.com"
Booo advertising a non-yc funded company.

(And the obligatory: Hooray unspecified chemically laced beverage!)

NuCaptcha solves the exact problems that the article outlines.
(comment deleted)
But you didn't say that. You said -> It's a true security offering that also improves input accuracy to 99%. !!!1!11ONE!

If you want to plug something on HN, first you need to disclose that you are doing some advertising. (kudos, you did this) And second, you need to explain, without weasel words, how and why it's a good solution for the problem.

Example of me plugging mongodb despite it only being marginally to the topic: http://news.ycombinator.com/item?id=1471516

[Deleted previous comment because I misremembered the thread I was replying to when I wrote it]

That's an interesting technique, but it seems like the human-detection is based more around it being a flash-based solution than any sort of obfuscation. e.g., if the text is always red, and always the same font (judging from the examples only), a screen capture of this would be far easier to decode than a regular captcha™. A flash-running bot should have a pretty easy time breaking it.

Granted, the current state of the captchas™ is kinda bad.

sigh.

you don't even appear to need flash, the swf apparently just downloads an mp4 that's actually just a concatination of flash params exposed in the initial page request. from there one would be able to crack the captcha even easier by using the fact that the captcha persists across many frames of the video in various orientations/perturbations (the first character is touching the second character on top for half the video and then on the bottom for the other half, or so for example)

gasp there's in addition to the mp4 and a completely different gif served with each request (To offer support for those without flash installed, of course!) that would provide even more data for figuring out the three red letters that persist across most frames of both animations...... :(

edit--the three combinations of letters(captcha solution) across the mp4 version, the gif and the mp3 appeared to all be different

voice recognition against the mp3 would be fun

Oh my god that's an absurdly terrible idea.

Using Flash for a Captcha seems like overkill. They couldn't come up with a more lightweight Captcha?

Why not use both anti-spam technology and CAPTCHAs?
To quote the article:

"We live in a world where spammers are a real problem and must be addressed, but CAPTCHAs are not the answer. You simply can not afford the friction. By using a CAPTCHA you are making the internet a whole lot less fun for all of us."

My local theater's site allows you to purchase tickets online. However, in the final ordering form, in which you enter your credit card details, there's a CAPTCHA.

What are they protecting against? Automated bots sending them more and more money?

The price of a single ticket is probably relatively small and so they may be protecting themselves from chargebacks. It is extremely common for those with stolen credit cards to test them using small value purchases. If you can find a site that doesn't rate limit your purchases in any way you can test a lot of cards at once, determine which cards are valid/active, and saddle the merchant account holder with tons of chargebacks and their associated fees.
I'd be very surprised to learn it was this complicated, but this is a very interesting take on it.

Do people tend to have such a bulk of credit cards/credit card numbers that they'd test them in such a fashion? And also, wouldn't it be very risky (detection/police wise)?

I can't speak to anything but my own experience. Having helped on a few ecommerce sites for very small merchants, the amount of fraudulent purchases that came through was staggering. One of those companies has been open for about six months now and is only breaking even in large part due to the expense of dealing with chargebacks. What they have observed is that a significant number of cards were tested through what appears to have been a rented botnet. Those went away with the addition of a captcha. The remaining fraud that looks like card testing (only purchases of low value items, with IP's far away from the billing address and similar peculiarities) are often done from Tor exit nodes.

Small merchants have very little support in this area. Local authorities often don't care or have the man power to deal with these types of issues. The banks and visa/mastercard also don't care since they just force the merchant to eat the costs and still collect all their fees. It would be very difficult to tie these transactions back to any one person in most cases as the tester is going to be using a valid card, valid billing/shipping address. Once they know the card works they can just have a mule go get a cash advance from an ATM or start having big ticket items shipped to various places for pickup. Or they just resell the card info as verified which increases the value significantly.

maybe just copying ticketmaster and trying to stop scalpers from being able to buy up all the tickets using automated scripts?