Re: [cgiapp] RFC: CGI::Application::Plugin::CAPTCHA

[Michael Peters <suppressed>]

Tony Fraser wrote:
> On Thu, 2005-08-25 at 09:56, Michael Peters wrote:
> 
>>I don't think the user should have to call create_captcha() at all. It
>>should be a run mode that is automatically added to the using app.
>>
>>
>>
>>>I think the above will work, but I'm not sure if I like how 
>>>verify_captcha() works.
> 
> 
> I don't see how this could work without cookies.

I've been thinking about this and still think the best way to go is with
cookies. It would be the simplest. But there are still ways to do it
without cookies.

If we have the create_captcha() run mode take an argument through the
url with the key then that key can be included in the form. For instance:

<form>
  <input type="hidden" value="my_key">
  <img src="/my_app?rm=create_captcha;key=my_key">
  <input type="text" value="" name="captcha_text">
  ...
</form>

Now you call verify_captcha() like so:
  $self->verify_captcha('captcha_text', 'my_key');

No cookies involved.

>>This is how I would do it. In create_captcha() create a random string
>>(using something like Data::Random). Then create a hash of that string
>>using crypt() (and a random salt from Data::Random again). Use the
>>password as the text in the image and pass the hashed value in a cookie.
>>
>>If the user then submits data, verify_captcha() should look at the field
>>in question, and then use crypt() again with the hashed value from the
>>cookie to verify that the string would indeed match.
> 
> 
> Using crypt() is a good start but better would be to use Digest::MD5 or
> similar with a server side secret like was discussed in the
> CAP::LinkIntegrety thread earlier. Also as was discussed in the
> CAP::LinkIntegrety thread it might be worth including the clients IP
> address in the hash.

The main reason I use crypt is because it won't give the same results
everytime with the same string. You just need to randomize the salt.
What are the advantages of MD5 over DES (which is what crypt uses)? My
understanding is that DES is actually an encryption but MD5 just creates
a digest, or summary. You can't break DES enrcryption except for brute
force, but digests can be reverse engineered (they just make it really
hard to change the original data without resulting in a new digest).

For instance, in LinkIntegrety, a digest is used not so the orginal url
can't be deciphered, but so that it can't be changed without the
'summary' changing.

Not that it really matters. CAPTCHA's aren't about security, but about
preventing annoying robots.

>>>I still have the following things I'm not sure about how to best 
>>>implement:
>>>
>>>- Image storage: I can either create the images on the filesystem, or 
>>>build them in a memory-based cache (which would mean the plugin needs 
>>>to add a runmode that returns an image only - doesn't sound like the 
>>>best way to me).  In any case, there needs to be a good way of  cleaning
>>>up old images.  Suggestions?
> 
> 
> I'd say save the images into a web accessible directory using the
> cryptographic hash as the filename. A simple "find /directory/of/images
> -ctime 2 -exec rm \{} \;" scheduled to run occasionally will take care
> of the old ones. Using a dynamic HTTP request just to serve 1 image
> seems backwards to me especially in a CGI environment where that would
> in tale a PERL interpreter startup.
> 
> I suppose as an alternate options to store the image in a memcached
> using Cache::Memcached could be added to the plugin. The downside I see
> to this is that you'd have to allot enough RAM to the memcached to store
> at least a few hours of images.

I'm still not convinced as to why we need image storage at all. I see no
reason that they can't be generated for each request.

>>The only issue that could be a problem with my approach would be if some
>>  or all browsers wouldn't accept cookies with an image. I can't imagine
>>why they wouldn't, but I've never tested it myself.
> 
> 
> Why use cookies at all? A hidden form variable would do just as well or
> better.

I would use cookies cause they would be more invisible to the programmer
and could be completely handled by the plugin. But as I pointed out
above, they aren't necessary.

> I'm working on project right now that would also benefit from a CAPTCHA
> plugin. I'd be more than happy to help out creating the plugin.

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed