“You cannot make a script to read an image from flash because a SWF file is a compiled files that contain executable code”

and

“The code is not visible to any user as HTML is”

but I feel that you are missing the point. When you generate a CAPTCHA string server side and send the string to the client to be processed into an image you are effectively providing the end-user with the solution to the CAPTCHA. This makes the CAPTCHA pointless as a rogue application could simply connect to your service and return the string that it was sent. I’m not quite sure why you have suggested using an SSL connection as this would only prevent eavesdropping between the client and server. By suggesting that you implement a CAPTCHA in this way you have just created a Token that would merely protect against Cross Site Request Forgery (XSRF) attacks.

To create a secure CAPTCHA in flex you would have to generate the image server side, not the string. This would have to be passed as a PNG or JPEG with a session variable to the Flex Client. The end user would then have to solve the CAPTCHA and return the solution with the session – this would be then validated server-side to determine if the end user was human.

CAPTCHAs do have a place within Flex applications, for example to challenge a user connecting to your AMF gateway when they get their password wrong multiple times. The key fact is that you MUST generate the CAPTCHA server side and pass it to the end-user as an image – if you don’t pass it this way you may as well just not bother.

If a client came to me and requested that I implement a client-side captcha to make the users “feel more secure” I would point blankly refuse. Giving users a false sense of security is plainly irresponsible – it would be far better to give them a true sense of insecurity and not implement the CAPTCHA at all.

First of all the article you refer to has the purpose to show how you can graphically create the image for CAPTCHA. Securing it afterward is the job of the server side programmer (the server side language can be any other language and I decided not to give a solution in PHP although I know PHP very well) together with the Flex/Actionscript programmer.

Hope this is clear now. I’ll move forward.

The CAPTCHA’s purpose is to keep away the robots (to distinguish the human from a robot). Well if you had been working with flex you should know that there are no cheap application to interact over a flash application. As far as I know there are no robots for flash movies/applications – the only ones I know about are complex expensive testing applications that need to be installed. You cannot make a script to read an image from flash because a SWF file is a compiled files that contain executable code. That is the difference between the HTML and Flash regarding security. The code is not visible to any user as HTML is. In my opinion a sign-up screen built in flex will not need any CAPTCHA at all because the robots won’t know what is in that sign-up screen not even if it is a sign-up screen.

A solution for the Flex/Actionscript CAPTCHA would be this…

Create a web service that will generate random codes for the CAPTCHA. The Flex/Actionscript CAPTCHA, when initialized will send a request over https protocol for a new code, will take it, will apply an algorithm on it, then displays it. The user will enter the visible code which will be sent back on the server (over HTTPS) which will compare with what was send, applying the same algorithm on the source code. The two should match. In order to know from which user the code has come we will use a server session variable when the HTML containing the CAPTCHA application is created. This will contain a code just for identification purposes (linking together the user with the server). This session variable will be made available in the Flex/Actionscript CAPTCHA (flashvars, url, etc). When the request for a new CAPTCHA code is send we will send also this server session code. The service will store both server session identification variable and the code sent in a database table then will send the CAPTCHA code needed. At submission we will send the code the user entered together with the server session variable. The session variable should match the one in the database and the code sent by the user should match the source code (saved also in the database) after applying the same algorithm used on client side.

This is one way to use it. And I think there are other ways too.

If you wonder why I used that CAPTCHA? Because a client really wanted it. Even after he understood that it is no need for a CAPCTCHA, he stressed that he wants it and that the users will feel more secure just seeing it there.

Hope now everything is clear.

For more info read my article on flexer.info.

At the end I want to rephrase this: Don’t use CAPTCHA on flash based applications… there is no practical need for it.