Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Execute Perl code on CGI submit for credit card encryption

by Popcorn Dave (Abbot)
on Aug 31, 2005 at 21:56 UTC ( [id://488245]=perlquestion: print w/replies, xml ) Need Help??

Popcorn Dave has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I've Googled and Super Searched this to no avail.

I've got a super small shopping cart I'm doing for work ( 5 items ) and I've got it almost all done but I've come up with a problem I can't solve, and I'm not sure I'm attacking it the right way.

I've set up the web page as a self referencing CGI script using https not plain http, which is all well and good, but when I get to the part to have people enter a credit card number for payment, I'm stuck on exactly when to do the encryption. I'm using Crypt::OpenPGP to do my encryption, but I'd like to do it when the submit button is clicked. I know things like this can be done in JavaScript with an -onSubmit but I'm curious how to do this in Perl - or if it's even possible. Trying to use Crypt::OpenPGP fails at present as there is no data in the form to encrypt, thus my question.

My other thought is: Am I barking up the wrong tree? Do I even need to worry about encrypting a cc number in a https post until it's a parameter on the new page? I can obviously easily encrypt the parameter once it's passed, but my concern is obviously security.

Thanks in advance!

Update: Sorry for being unclear. I wasn't trying to do my encryption in JavaScript, but rather emulate the -onScript function in the submit using Perl code rathe than JavaScript.

Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.
  • Comment on Execute Perl code on CGI submit for credit card encryption

Replies are listed 'Best First'.
Re: Execute Perl code on CGI submit for credit card encryption
by Codon (Friar) on Aug 31, 2005 at 22:06 UTC

    Your communication is already over a secure connection. You should have a reasonable sense of security here. If my understanding of HTTPS is correct, the client browser is encrypting all data, sending it over the pipe, and then the receiving server is decrypting the data to hand it off to the processing script (your CGI). I would imagine this to be sufficient.

    Ivan Heffner
    Sr. Software Engineer, DAS Lead
    WhitePages.com, Inc.
Re: Execute Perl code on CGI submit for credit card encryption
by shiza (Hermit) on Aug 31, 2005 at 22:00 UTC
    I'd say using SSL is all you need for the initial post from your form. Also, using any type of Javascript encryption is pretty much useless. Anybody could view it and see exactly how you were encrypting the data.

      If you did public key encryption in JavaScript, you could see how the data was being encrypted and the public key being used, but still couldn't decrypt it without the private key.

      This is how HushMail.com does client-side encryption, using Java instead of JavaScript.

      But for this application, SSL is the normal way of doing it, and is probably better unless you have a lot of experience writing encryption software and a penchant for doing things your own way.

      I wouldn't say it's useless. In a proper encryption scheme it is assumed that your enemy has full knowledge of the implimentation. I have seen Javascript implimentations of public key systems, which are perfectly secure as long as the private key is secure. Someone looking at the code would still not be able to decipher the transmission unless he somehow got the private key.

      But in this case, using SSL (which is a public key system!) seems sufficient.

Re: Execute Perl code on CGI submit for credit card encryption
by jk2addict (Chaplain) on Sep 01, 2005 at 13:03 UTC

    Building a shopping cart from scratch? I will now whore myself out and kill my XP. I got tired of having to do the same thing over and over in that area, but didn't want the huge buren of things like OpenInteract2, and the like. I came up with this. Handel is available on CPAN.

Re: Execute Perl code on CGI submit for credit card encryption
by bradcathey (Prior) on Sep 01, 2005 at 01:05 UTC

    First of all, I recently posed a similar question concerning security. There's a little summary on how I structured the whole transaction that you might find useful.Check it out.

    As an update, I'm encrypting and storing the key in the DB and encrypting the credit card number with the key and writing it to a cookie. One is no good without the other, as they are being stored in two separate places.


    —Brad
    "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
      Thanks for that! I had thought about wiping the field with the credit card number, but mattr's suggestion of filling the field with random junk is intriguing and probably a safer way to go.

      My app isn't quite as sophisticated as what it appears you did. I'm still going to have to enter the cc numbers in to a terminal for processing, but it's a family business (wife and in-laws) so the theft angle isn't quite the same. Of course I'd *love* it if the whole thing grew to where I could justify online processing, but you have to start somewhere.

      Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.
        If the terminal you manually enter the CC-number into is not connected to your web-server or to the internet you have a super-secure system as nobody can "jump" from the web-server into your CC-number storage! You will only have to physically secure your terminal from theft (some "old style" ferocious dogs and/or shotguns might be sufficient here).

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Execute Perl code on CGI submit for credit card encryption
by zentara (Archbishop) on Sep 01, 2005 at 10:30 UTC
    Encrypt it before you write it to disk. If it comes in over https it's already encrypted, and there is nothing you can do about the exposed number sitting in the system ram, because you have to be able to see it, to process it. But encrypt it before you write it to a disk file, or transfer it via ethernet to another computer.

    I'm not really a human, but I play one on earth. flash japh

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://488245]
Approved by BaldPenguin
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2024-04-25 06:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found