Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi PerlMonks

I'll explain the program I have developed and I'd like to know your suggestions/thoughts on the security of it ..

It is an ordering script which will handle cc data and process cards through a merchant gateway - because it will handle recurring transactions these cc numbers must be encrypted and stored in the database. Now what I think is best is that the data is encrypted with an encryption string defined in the script and then the admin approves the new customer and assigns it a new encryption key and that will be used when running it in future (and will not be stored on the server).

Now, my concern is with the initial encryption as the encryption method will need to be in the script so it can be decrypted - should I somehow hide the source of the encryption/decryption file? I did a search here and discovered Bleach, but it appears that the source can be revived from that. It needs to be portable also.. Would love people's opinions on this, I apreciate any feedback. Thanks

Replies are listed 'Best First'.
Re: Strong Encryption
by no_slogan (Deacon) on Mar 11, 2002 at 22:04 UTC
    If I understand correctly, you want the web front end to be able to encrypt credit card numbers, but not decrypt them. This sounds like a perfect application for Crypt::RSA. Give the front end the public key, and hide the private key wherever you want to be able to decrypt the credit card information.
[reply]
Re: Strong Encryption
by derby (Abbot) on Mar 12, 2002 at 01:38 UTC
    AM,

    Having done this a few times, you should think about other stuff in addition to the encryption (tho that's core). I suggest going with GPG it's relatively easy to use and the GNU people have some very good documentation

    There are a few other things you should worry about:

    • storage protection - if it's in a file, is the filesystem secure enough? In a database? Is the database locked down properly?
    • changeability - can the user change the CC in the future?
    • viewability - do you want to show the user the CC number again? If so, as the full number or masked (XXXX-XXXX-XXXX-1234)?

    What I've done in the past is store the CC numbers in a fairly secure database. The schema would have both an "encrypted" field and a "plaintext" field. When the user enters a number, it's stored in the plaintext field. Then a cron kicks off every X number of minutes to do the encryption. If encryption succeeds (it always has), the plaintext field is masked.

    This gives me control over the encryption and simplifies it - I only have to worry about two keys - the user that encrypts and the user that decrypts. Trying to control a key for each user would be unwieldy for me (but may be fine for you). Given that everything else is fairly secure (till the next bug report), I have a layer of security at the firewall, a layer at the database, and a layer with encryption.

    If the first two layers fail, I may loose X minutes of clear text CC numbers but I gain a lot in performance. By showing just the masked CC, I can stay in http (vice https) and there is no need to decrypt.

    Some PHBs may crow about those X minutes but I always counter with the restaurant question - Did you give your CC to some unknown waiter who wandered off with it for 15 minutes?

    -derby

    update: I just re-read your question and I don't think you want to use symmetric cryptography at all. There would be no easy way to obfuscate the encryption key in your script. Asymetric (public key) crypto is definetly the way you want to go. And you want to have two keyrings. One for the front-end webserver and one for the back-end reporter. The front-end would encrypt with the back-end's public key, that way if your front-end user is compromised, the encrypted data still has a layer of protection since the front-end keyring cannot decrypt. Definetly read the documentation for GnuPG.

    another update: Sorry for not being clear GPG (the one actually named GPG) is just a thin wrapper on top of the Gnu Privacy Guard. There are several public key perl modules - I found GPG and the Gnu Privacy Guard the easiest to get started with.

[reply]
Re: Strong Encryption
by Ryszard (Priest) on Mar 11, 2002 at 23:21 UTC
    I agree with no_slogan, use RSA (or another public key system).

    One thing I dont think will scale well is the use of a human to aprove the addition of new credit card customers.

    What would you do if you've got a high transaction site with people wanting to spend their money right away? If you have a human aproving the credit card before use, you'll get too much lag and people will go elsewhere (I would).

    I'm assuming you'll be doing this to protect yourself against fraud - what'll happen if a person gets their cc stolen, and needs to add another card? They'll have to "re-apply" and wait another period of time until their application is processed. IMHO I reckon you can automate all this. It will save lots of time and money. Check out www.amazon.com they do (at the front end) what I personally think is a good method of handling cc transactions.

    Otherwise I think if you store the priv key "offline", perhaps on a private network somewhere behind your font end, and have a seperate machine to handle your ecommerce gateway (and only your ecomm machine can access your private key machine), you could be fine.

    I havent had any real good commercial experience in ecommerce systems (yet), but the above sounds kinda logically secure - I wouldnt mind seeing what other people have to say.

[reply]
      Check out www.amazon.com they do (at the front end) what I personally think is a good method of handling cc transactions.

      If you can't get enough info from their website, you may wish to read Amazon's patent to get a better idea of how their system works. After that of course don't plan on doing anything like it, unless you want to pay them a whole lot of money.

      Then read Why Boycott Amazon?

      Oh, and just so this is still Perl-related, I highly recommend Crypt::RSA as well.

[reply]
        Amazon certainly sucks in this regard. I guess I should hurry up and submit my "Removal of Human Waste via a Network of Pipes." idea. I'll be rich. You can't hold it forever!

        In all seriousness, I can't believe how many patently obvious ideas are granted patents. (use Bad::Pun)

        -Lee

        "To be civilized is to deny one's nature."
[reply]
Re: Strong Encryption
by BMaximus (Chaplain) on Mar 13, 2002 at 00:06 UTC
    I agree with most of the individuals who have posted comments on the subject. However it also should be noted that a good merchant gateway provider will also provide a means of setting recurring transactions for subscription purposes. Letting them store the CC number instead of having you do it. The benefit of letting them do this work is that they would have better security to protect the card numbers as well as the fact that if they get hacked, their insurance can pay for any damages incurred if the numbers get stolen and used. Also it saves you time, money, drive space and worry. If your business gets hacked it has a high possibility of ending it.

    BMaximus
[reply]

Back to Seekers of Perl Wisdom