The CAPTCHA example is incomplete. It is missing the part that actually makes it difficult for robots to solve. The purpose of the example was to provide a list of ways to implement an effective CAPTCHA.
I am not the author of G-WAN. I am not claiming to have done anything.
This whole thread is based on a misunderstanding. G-WAN does not have any CAPTCHA support. The example merely demonstrates how to use G-WAN's image generation API.
The CAPTCHA example is not meant to be used without modification in an application. CAPTCHAs are not a feature of G-WAN.
No where did anyone claim to have invented stateful web applications.
I do not have an example handy, so hopefully an explanation is enough.
The CAPTCHA example has two parts: generating the CAPTCHA values and presenting them in a way that is easy for humans to solve, but difficult for computers.
This example only implements part one, but gives some methods of how one could implement part two. This is why it is so easy for you to write a script to solve it.
Using mouse cursor hovering, one could change the background color behind the image based on an event (such as a mouseover of an input field) that is probable for a human to make, but less so for a computer. This is difficult for a computer to solve, but not impossible to break.
G-WAN applications are persistent, meaning it is trivial to record stateless actions the client has made in the past for use in the future. The client would have to provide a known good value from the past in order to solve the CAPTCHA. This is what is meant by "previous state or shared secret".
> Using mouse cursor hovering, one could change the background color behind the image based on an event (such as a mouseover of an input field) that is probable for a human to make, but less so for a computer. This is difficult for a computer to solve, but not impossible to break.
How would this reveal the CAPTCHA value to a human but not to a computer? If the string is readable over only some background colors, then it's written on a transparent-backed image, so the whole background-changing script can be ignored. Just OCR the image with the transparent background.
If you're suggesting the CAPTCHA itself be the movement of the mouse over specific inputs, rather than deciphering a string, then this is trivial to break as well. The code that watches the mouse events and does whatever it does to indicate human-ness has to be written in JavaScript and transmitted to the browser... which means it's sitting right there to be analyzed and copied by the bot author. They don't need to replicate the mouse movement, just trigger the same code the correct movement triggers.
Requiring previous state adds nothing to the test either. If a human has to visit a certain sequence of pages before submitting a form, the bot can make the same sequence of HTTP requests and replay the same cookies or however you track the state.
It doesn't sound like you know what you're talking about.
> If the string is readable over only some background colors, then it's written on a transparent-backed image, so the whole background-changing script can be ignored. Just OCR the image with the transparent background.
The CAPTCHA image contains false values for misdirection, hence the requirement of running the background changing script.
Here is a list of claims made on the example CAPTCHA page:
BG Ability
color to
generation solve (as defined by the author)
---------- ---------
mouse cursor hovering difficult
previous state impossible
input
shared secret
I have no way to know precisely what the author means by those words since the given example does not demonstrate any of them. I cannot match the left and right columns.
For example, if I claimed that a CAPTCHA based off a "shared secret" only a trusted user has is impossible to solve, then one might ask the question, "Why is a CAPTCHA needed for a trusted user?". Is this what the author of the CAPTCHA example meant? I do not know.
My only purpose of posting in this thread was to show that the OP's premise that "this is the best example of how not to implement it." is flawed because no such example was given in the first place.
Nothing about that sounds unique from existing CAPTCHA systems, nor does it sound hard to break. You're going to use CSS or Javascript to "hide" it from a computer? That uhm, doesn't make much sense (to me).
Not to mention something like Sikkuli (in JPython) can actually make your mouse hover and record values...
Plus how is that easy for humans to solve?
1. They need to know they can put their mouse over the text
2. Then record the text
3. Sum the numbers
4. Write the result...
If I had to do this every time I wanted to login to a site I'd seriously consider switching. And this is the 'best' captcha impossible to break - for humans. Machines can solve it easily.
