The older versions had that problem you’re talking about, though.

Basically all the verifications are checked only on server-side, so the script allows you to put anything on it.

It is true, however, that by automated randomized guessing it’d be possible to find a solution. That’s why we implemented the nonce in it (like Wordpress does it).

var key = $(’.wozia-captcha strong:first’).text().toLowerCase();
var data = {draggable: ‘.wc-’ + key};
$(’.wozia-where2go’).droppable(’option’).drop(null, data);

If the keys were randomized for each icon, and stored with the jquery data() method rather than as an attribute, it’d make it a bit tougher, but there’d still be a 20% chance to get it right with automated randomized guessing.

Athman’s solution has the same issue as the other drag-n-drop capcha: it’s not testing to see if the correct item was dropped, it just assumes that it was. So the same simple foil works:

$(’.ui-droppable’).droppable(’option’, ‘drop’)()

$(’.ui-droppable’).droppable(’option’, ‘drop’)()

So it actually makes it easier for automated attacks. I guess it’s only meant to slow down attacks by really dumb people.

1. Client registers to download script. Is issued with an application key and a secret key. They put this in config.php in the downloaded files as configuration.

More info and usage at http://www.webdevlabs.net/2010/09/wcaptcha-better-captcha-alternative.html

1. Client registers to download script. Is issued with an application key and a secret key. They put this in config.php in the downloaded files as configuration.

2. Client’s user loads form, which has not submit button or location of submit processing PHP file for the form. The FACTCHA calls a local server script captcha/captha.php which in turn does a file_get_contents(”http://someserver.com/captcha.php?site_key=”) where is the one in the config file.

3. someserver.com/captcha.php uses to check into its DB if this is a registered site, if not it returns an error code. If registered, then it calls the Millenium Development Goals database, formulates a and a , encrypts them using the site’s retrieved from database authentication and also generates an and sends it back to client server.

5. client server receives info, decrypts using its from config and sets the appropriate sessions using the access_token passed from server.

6. user drags and drops the correct icon, the data is saved into a hidden element whose names is earlier generated by server. this is to ensure all these elements are unique. The submit button is displayed and the submit processing form is attached to action_tag of the . Also, the fact obtained from database earlier is displayed.

7. On submission, the client captcha/captcha.php checks against the sessions set earlier and only if correct forwards the form for processing.

I was hoping:

1. By making sure the hidden input is randomly named, then it would be harder to have a bot look for it.

2. Even if it does look for it, the names of the sessions storing the data to be compared against are random.

3. Even if the form was submitted by the bot bypassing all the fancy stuff, the sessions which are named randomly have to be checked correctly for the form to be processed.

4. The encryption bit using secret keys for data passing between ajax client and client captcha/captcha.php and between server’s captcha.php and client’s captcha/captcha.php will not allow anyone to read the data directly by just calling up those scripts on the browser.

5. The database could as well have been on the client, but for ease of maintenance i put it on its own centralized server… hence all FACTCHA’s everywhere will have to connect to this server. Maybe statistics could be obtained from it?

I may have missed the boat completely but comments are welcome for improvement.

http://demo.modernization.co.ke/factcha/client/form.html