in reply to Re: need suggestions on Perl modules to support Encrypt Data
in thread need suggestions on Perl modules to support Encrypt Data

Hi, moritz:

Thank you for your replies.. there are some examples that I used encrypted string on the URI: one is the CAPTCHA strings that send to GD::SecurityImage to dynamically generate images and do the autntication from the sender.. I canot get another idea to handle this, so I send the encrypted string on the URIs... Another implementation is when something like directory names shown up in the URI, i.e. "http://example.com/ask.html?D=/path/to/a/diretory" , I want to flatten them(not for high security info, I can use pack|unpack with 'H*', but want to add some light ciphered info, BTW these URLs are not frequently visited links)

Can you recommend some methods or modules which can solve these problems nicer. many thanks :-)

H.

  • Comment on Re^2: need suggestions on Perl modules to support Encrypt Data

Replies are listed 'Best First'.
Re^3: need suggestions on Perl modules to support Encrypt Data
by moritz (Cardinal) on Oct 28, 2007 at 21:46 UTC
    For the captchas: store the string and a session ID in a database, and only send the session ID to the user.

    You could use that scheme for the paths as well, or if you want some light weight encryption, check out RC4. That's very easy to implement, but sadly not very secure. But secure enough to keep the occasional script kid off.

      For the captchas: store the string and a session ID in a database, and only send the session ID to the user.

      Is that necessary?? the captchas used only once and then thrown away. :-)

      You could use that scheme for the paths as well, or if you want some light weight encryption, check out RC4. That's very easy to implement, but sadly not very secure. But secure enough to keep the occasional script kid off.

      Many thanks, this is the one I need to try on my problems.. :-)

      H.

        You have to store something in order to provide a secure captcha. If you don't store anything, a malicious user agent could always return the same combination of text and encrypted data, and it would always pass.

        You could limit that with timestamps, but then you force all legitimate users to respond in a timely fashion - not a good idea.

        Is that necessary?? the captchas used only once and then thrown away. :-)

        That's exactly what sessions are for. You don't have to use a database, though, you can use Apache::Session::File to store it on the file system. Sessions have a specific lifetime, so if that amount of time has gone by and the session hasn't been used, it will be cleaned up anyway, it's not like you're losing any processing power or storage space, even on a large site. It will also be easier to code, in my opinion.