Why you should never use a CAPTCHA
onlineaspect.com
onlineaspect.com
What are they protecting against? Automated bots sending them more and more money?
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)?
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.
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.
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?
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.
/*
* 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/
*/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?
If I wrote this article, it would go...
Why you should never use CPATCHA:
Because reCAPTCHA exists. You should be using that instead.
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%.
Disclosure: I've advised with NuCaptcha on a pro bono basis.
(And the obligatory: Hooray unspecified chemically laced beverage!)
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]
Granted, the current state of the captchas™ is kinda bad.
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
Using Flash for a Captcha seems like overkill. They couldn't come up with a more lightweight Captcha?
Wonder how it works if you have javascript disabled, or are using a text-only browser, or have NoScript installed.
"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."