captchagen
Posted: Sat Nov 01, 2003 5:02 pm
Syskoll,
I just had a change to play with captchaget -- pretty cool!!
I added a sudirectory called web to the captcha subdirectory in the test home dir. This directory can be browsed at test.spamgourmet.net/tmp
I'm working out how to plug it in. We'll need to move the account signup form onto its own page so that we don't need to have one of those images on every page -- alternatively, we could leave the form where it is, then add the challenge as a last step (probably moving the password part there, so we don't have to send it back to the browser for resubmission from the challenge page).
I also have the challenge of not having root on the webserver machine, and so not being able to easily install Image::Magick or File::Temp (I can work around those problems eventually, of course).
Here's one approach --
a) when the challenge page is created, it calls captagen with a safe random filename (perhaps a hash of the proposed username) that creates the file in the sg web folder. It receives the word (probably lc()'s the word), and uses a private hash algorithm to create a hash that is included as a hidden input (I guess this could be the filename, for that matter) -- the image is included on the page
b) when the user submits the challenge form, the user typed word (probably lc()'ed) is hashed using the private algorithm to see if it matches the hidden input. If so, create the account.
The only wrinkle if we have to run captchagen on the mail server machine (where we have root) is that the call from the web code to captchagen will have to be remote.
This was just my first stab at it -- there may be a cleaner way. I'd love to not have to store the images, particularly if we're on the webserver machine (they're pretty big), which would involve causing captchagen to return the png straight to STDOUT instead of the word. I haven't been able to work out an implementation strategy for that, though.
I just had a change to play with captchaget -- pretty cool!!
I added a sudirectory called web to the captcha subdirectory in the test home dir. This directory can be browsed at test.spamgourmet.net/tmp
I'm working out how to plug it in. We'll need to move the account signup form onto its own page so that we don't need to have one of those images on every page -- alternatively, we could leave the form where it is, then add the challenge as a last step (probably moving the password part there, so we don't have to send it back to the browser for resubmission from the challenge page).
I also have the challenge of not having root on the webserver machine, and so not being able to easily install Image::Magick or File::Temp (I can work around those problems eventually, of course).
Here's one approach --
a) when the challenge page is created, it calls captagen with a safe random filename (perhaps a hash of the proposed username) that creates the file in the sg web folder. It receives the word (probably lc()'s the word), and uses a private hash algorithm to create a hash that is included as a hidden input (I guess this could be the filename, for that matter) -- the image is included on the page
b) when the user submits the challenge form, the user typed word (probably lc()'ed) is hashed using the private algorithm to see if it matches the hidden input. If so, create the account.
The only wrinkle if we have to run captchagen on the mail server machine (where we have root) is that the call from the web code to captchagen will have to be remote.
This was just my first stab at it -- there may be a cleaner way. I'd love to not have to store the images, particularly if we're on the webserver machine (they're pretty big), which would involve causing captchagen to return the png straight to STDOUT instead of the word. I haven't been able to work out an implementation strategy for that, though.