Use of an Applet for Captcha?

[philfrei]

Hi - I've seen a couple posts on JavaGaming where the possibility of using an Applet (call it a Gamelet?) as a Captcha comes up. Usually the notion is shot down, but I really did like the suggestion of a mini-frogger game.

OK, so http://www.adonax.com/Jean/BotBlocker/ is a link where I wrote a little char-matching Captcha as an experiment. The inspiration came from playing around with an idea that prevents images from appearning in a screen capture. The jar is lightweight and loads very quickly, yes? (Tested on IE8, Firefox & Safari on Windows, Safari on Mac.)

I am interested if people think that an Applet is simply out of the question as a Captcha or if there are some possibilities here. I'd be happy to donate the use of this or something with some modifications (am VERY open to suggestions) to JavaGaming if folks think there might be a use for it. If ANY site could get away with it, wouldn't this one consist most entirely of people who already have the Java Plug-In in their browsers?

Thanks for any comments and discussion,

Phil Freihofner

[Matzon]

uh very nice! - not able to take a screenshot and easily readable as a human. would like it to be case insensitive tho. Good work!

[Markus_Persson]

There's one major flaw; the applet needs to know what two letters to display. That means it's trivial to write a program to extract those letters.
One way to get around that would be to stream a video that has the same effect as this applet.

It's a very nice solution otherwise. I spent some time trying to make an image-based cracker, and this is about how far I got:

(The solution was "Qd")

Games published by our own members! Check 'em out!

[JL235]

First it's a nice idea; but I don't think it would be that difficult to beat. You don't even need to take a video stream as Markus suggests; just several screenshots in a row is enough and then analyse the pixels across them. Outliers (the random images appearing in between) could then easily be caught out and the original letters and the random pixel background is all that is left. Now your left with an old style captcha.

However you could (or should) never use this in practice because it could cause epileptic seizures (I personally find it very difficult to watch).

But I will give you credit that it does load quickly on my PC. Typically all applets (even small ones) grind my laptop to a halt for half a minute whilst it boots; yours doesn't (I'm on CrunchBang Linux btw).

To date the only captcha I've heard of which is (supposedly) unbeatable is one that shows pictures of animals and asks you to count how many there are of each type.

[DzzD]

nice idea, but the main idea of captcha image is to be generated serverside, anything that would work/produce the image/video/ilusion clientside will enable a robot to be build (playing a streaming video of the ilusion will work)


useless too (but funny) would be a stereogramme image that display the secure code :



this way you know visitor is a human but also it have two eyes (and a headack)

[philfrei]

Dang, you people are good!! I went to put in the case-insensitivity for Matzon, and come back to find OCR-based cracks. It lasted less than 12 hours. I am in awe.

May I ask one question? What difference does it make that the challenge.jar code (client side) originates the string to be matched? At what stage would a "robot" hook in? If the Applet calls code in a second JAR that invokes the server, there is no way to interpose, is there? And if it is all compiled code, there should be no way to find the required syntax of the call to the server (assuming a "solve" generates a passcode that is included in the server call).

I suppose one could try harder or smarter to make "noise" that would be more difficult to filter out. The concept is that one should be able to pile on more junk and distortion with an animation than with a static image given the possibility of flickering at a rate that is too fast to see. The Timer is now set to issue repaints every 15ms, which is pushing the event queue, but maybe one could speed that up even more or vary it. But it seems some of you could probably still filter the results without breaking a sweat.

For the quick loading speed: maybe part is that this is self-contained code? There are no image files to reference. Also, it is only 12KB. Maybe one or more of the 4KB challenge candidates could be converted to applets used for Captcha? A game-based Captcha would make a lot of sense for this site. A hand-built frog for example (for mini-frogger) should be small and quick to create via directly loading a BufferedImage.

I've added a couple components I made from a puzzle app (under development) that make BufferedImages on the fly, to demonstrate feasibility. www.adonax.com/Jean/BotBlocker/

[DzzD]

What difference does it make that the challenge.jar code (client side) originates the string to be matched?

difference is that captcha is used to ensure to the server that the visitor is not a robot, so at sometime the server must know the security code.

In your sample this is a random generated string (client side) of 2 characters, but now how would you tell to the server that the client is not a robot ?
you will probably send a boolean flag to the server saying the client is ok, but this network packet can simply be reproduced (using proxy, wireshark or equivalent software)
another possible hack would be to grab you applet jar file and then disasseble, modify & recompil it

1 - the security code must not be transmitted by network in a readable format : must be sent to the client as an image / a video
2 - the code entered by the visitor must be sent to the server : the server have to validate or invalidate it (not the client)

this way the client never really receive/know the security code, and the algorithm to decode the security code is not present on the user computer (transfered in an image with some noise, your client application must NOT be able to decode the security code)

[philfrei]

Thank you DzzD, for the explanation. I hadn't realized how easy it was to intercept and duplicate network packets, nor that a jar can be "uncompiled" so readily. Oh well!

Many thanks for the feedback!

[DzzD]

Thank you DzzD, for the explanation. I hadn't realized how easy it was to intercept and duplicate network packets, nor that a jar can be "uncompiled" so readily. Oh well!

Many thanks for the feedback!

Here is a sample of what I mean by hacking jar file

http://demo.dzzd.net/BotBlockerHacked/

here the solution is always the same "DzzD"

[philfrei]

OMG! (Laughing!) I am so naive.

Well done!