Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Encrypting Credit card numbers

by petethered (Pilgrim)
on Apr 21, 2001 at 22:43 UTC ( #74455=perlmeditation: print w/ replies, xml ) Need Help??


<edit> Just to clarify, I HAVE to store the credit card numbers since the cards will need to be automatically rebilled.

If It was just onetime transactions, there would be no problems.</edit>


Recently an intresting problem has fallen in my lap.

How to securely store creditcards to make them safe incase of a system penetration.

Now, if the transactions I was expecting were one time transactions ( a sale for example ), I would store everything but the last 4 digits, and If the customer was going to make another one time transaction, just ask for the last 4 digits.

But my problem is that I'm expecting recurring billing. A transaction every month , without having the customer to re-enter any information ( for a service based website. Not pr0n ;) Those were my younger broker days ;)

So i'm forced to store credit card numbers. But every day in the news you read about X site being penitrated and Y number of CC's stolen.

Well, I have come up with a number of possible solutions, and im hoping the Monestary can think of the best way for me to do it.

  1. Not encrypt them at all, dubed the "Pray" method. Pray that the system doesnt get penetrated. Rely on MySQL's internal access tables to protect it, and the servers hosts.allow/deny and patches.

  2. Use a simple find and replace encryption. Ie, scramble the numbers up based on a precreated hash. Could be made stronger by randomizing the hash based on a timestamp. THis is easily hacked if the source code is read. Billing can be automatic.

  3. Use PGP. Encrypt the card number with the public key for storage into the database, then have an administrator billing interface where the Private key is cut and pasted into a textbox and the cards are decrypted for billing. Pretty secure, but all a hacker has to do is alter the source code to capture the private key and/or the cc number after its decrpyted. Billing is not automatic since the admin has to enter his private key everyday

So, as you can see there is no perfectly secure way of storing the cards, unless I missed something. Im leaning twords the PGP encrpytion but the annoyance of having to manually do the recurring billing may not make it fly with the boss.

So monks, is there anything I missed?

Pete

insert into pete values('red hair','near green eyes','overinflated ego');

Comment on Encrypting Credit card numbers
Re: Encrypting Credit card numbers
by little (Curate) on Apr 21, 2001 at 23:13 UTC
    One table might contain the half of the digits of the CC and another one the other half, a third table (or more) might contain the rest of the data.
    Now you need a table that holds all the relations between them. That table should be encrypted using MD5 or something alike. (better don't forget to change the passwd/ encryption string) Don't save the data on your webserver, better forward these as encrypted info to your "eyeball.backedup.lockedup.secured.intranet" server:-)
    Each time a client wants to buy, just assure that he is who he claims to be by using somewhat authentication and then only forward refrences to his user info stored on your intranet server, where you need some tool to generate the billing process, cause you can bill CC also in real world.
    Thats just an idea :-)
    But you could aslo use a third party for that process so they get blamed if they get hacked :-)
    Have a nice day
    All decision is left to your taste
Re: Encrypting Credit card numbers
by Beatnik (Parson) on Apr 21, 2001 at 23:38 UTC
    There are loads of other encryption modules... Rijndael is currently my favorite...

    Greetz
    Beatnik
    ... Quidquid perl dictum sit, altum viditur.
      Don't forget to mention that it was selected as the AES standard for a replacement to DES. If it fits whatever problem space you are working on, you can use it and then compliment yourself in your advertising of using a standard that is likely to be officially approved by the US for a decade or 3...

      In other words if you just need encryption and have no particular reason to choose one over another, then Rijnael should be your choice.

Re: Encrypting Credit card numbers
by TStanley (Canon) on Apr 21, 2001 at 23:44 UTC
    I work for an online payment processing company, and our software stores the CC number
    in the database using the Blowfish encryption method. You could store the key needed to
    encrypt/decrypt the data in an initialization file and read it in from there.

    TStanley
    In the end, there can be only one!
      And every kind cracker would not read that initialization file?
      Have a nice day
      All decision is left to your taste
(dws)Re: Encrypting Credit card numbers
by dws (Chancellor) on Apr 22, 2001 at 03:10 UTC
    If you want to protect sensitive information in the database, don't allow the web server to communicate directly with the database server.

    This has a couple of implications:

    • The database server needs to live on a separate box from the web server. If it doesn't, and the web server is hacked, all bets are off. Having the password encrypted in the database won't help you if the encryption algorithm and keys are exposed.
    • The database server must not accept connections from the web server box. If it does, and someone hacks the web server box, all bets are off.
    • The database box should not accept connections from the internet in general (with the possible exception of an SSH). Otherwise the database server is hackable, and all bets are off.
    • The web server communicates with the database server through an intermediary in a protocol that does not include raw SQL. Otherwise, the hacker can pass SQL through the intermediary, and all bets are off.

    The intermediary is an "application server", and is either housed on its own box (a "three tier" configuration), or it's colocated with the database. (Big players go three tier, with firewalls between each tier).

    Writing a simple application server is actually pretty easy. Code for accepting socket connections is widely available, so that part shouldn't be too difficult. (Lincoln Stein's Network Programming with Perl is a great reference.) Accessing the database is also pretty easy.

    The trickier part is in designing the protocol. A simple way to start is to look at your existing queries in terms of inputs and outputs, and to wrap each query up inside of a "command" that the web server will then send to the application server. If you use XML to express the inputs and outputs, you're on the road to XML-RPC or SOAP.

    If you get this far, and assuming that your application protocol doesn't include something like getAllCreditCardNumbers(), then the credit card data as a whole is probably safe, though encrypting it in the database might help you sleep at night.

      Hmm... this is an intresting solution if the credit card number never gets passed back to the webserver or the intermediate server.

      Inital Process:

      1. CC number gets sent to DB server and gets returned a "key" to reference it for storage in the noncritical database.
      2. Uses said reference "key" to request that the card be processed.
      3. Intermediate server sends request to CC storage server who then processes the card and sends the request code to intermediate server who sends to webserver.

      Rebill Process:

      1. Billing software sends "key" to intermediate server with a price to be billed.
      2. intermediate server relays request to database server who then processes card and sends response code back
      3. Intermediate server returns status code to webserver

      I dont see any real problems in this process. Credit cards go in but they dont come out.

      Intresting solution.

      Pete

      insert into pete values('red hair','near green eyes','overinflated ego');

Re: Encrypting Credit card numbers
by ncw (Friar) on Apr 22, 2001 at 05:36 UTC
    An interesting problem and one which I've had to face!

    My ultraparanoid assumption is that any internet connected machine can be hacked by a sufficiently skilled and determined cracker. Remember that someone really serious might come after you. If you have 100,000 live credit cards in your database this isn't script kiddie territory this is organised crime territory...

    Anyway enough paranoia. I think you've got two choices.

    1. Don't store the credit card numbers
    2. Store the credit card numbers so that they can't be recovered using info on internet connected machines.

    2) means PGP with the secret key on your isolated back office machine. This doesn't mean you can't automate the rebilling process just that it will be done from the back office machine. Nothing else is good enough - a symetric cipher (like blowfish etc) is worthless since the key will be available to the webserver. Same with the hashing scheme.

    PGP with the public key on the webserver and the private key in the back office is the only way to make it work cryptographically speaking - you need an asymetric cipher to satisfy 2) and RSA is the best method at this point in time. If a cracker came in and owned all the internet connected stuff they would have to crack a 2048 bit RSA key to recover credit card numbers which is an acheivement worth much more than a few million credit card numbers!

    Your suggestion for a token passing system is good, but fails my paranoia test since the CC processing machine does need to be internet connected. It is do-able with careful firewall design and if 1) or 2) wasn't acceptable then its the scheme I'd go for.

    When I had to make this choice I chose option 1) - I really didn't think the company could stand the potential liability of hundreds of thousands of credit cards being exposed to the internet. Every time I hear of a database of credit cards being ripped off I'm sure I made the right choice ;-)

Re: Encrypting Credit card numbers
by turnstep (Parson) on Apr 22, 2001 at 15:38 UTC
    Im leaning twords the PGP encrpytion but the annoyance of having to manually do the recurring billing may not make it fly with the boss.

    Yes, and when the credit card numbers get stolen, and you lose all of your existing customers, and get bad publicity to keep away all new ones, and the business shuts down, *that's* annoying. This is one area where it should be fairly easy to explain to the PHB that the price of security is definitely worth the cost. (three-machine, encrypted, at the least).

Re: Encrypting Credit card numbers
by toadi (Chaplain) on Apr 22, 2001 at 19:22 UTC
    Well,

    Don't know about the laws in your country. But I'm from Belgium and there it's illegal to store creditcard numbers!

    Off cource they get stored... But it is illegal....

    --
    My opinions may have changed,
    but not the fact that I am right

Re: Encrypting Credit card numbers
by diskcrash (Hermit) on Apr 23, 2001 at 02:07 UTC
    Dear Pete-

    In your original question -

    How to securely store credit cards to make them safe in case of a system penetration.

    Don't forget the low tech, Kevin Mitnick style, social engineering. If you get enough credit cards, as previously noted, you become an attractive target.

    Consider:

    • Who has physical access to any system that has these numbers?
    • Are the passwords written on the monitor?
    • Where and how secure are your backups?
    • Are there operators who have been warned against sneaky people calling up seeking "help"?
    • Is the server room decently locked up?
    • Does just anyone have the ablity to come and go?
    • How good is the security of the back end that clears the transactions?
    • Do you actively patrol the security updates for the OS?

    Sometimes the fancy lock pick is a crow bar. -Diskcrash

Re: Encrypting Credit card numbers
by spacewarp (Pilgrim) on Apr 23, 2001 at 07:33 UTC
    I freely admit that I have no experience encrypting sensitive data, but as I read through the responses on this thread, a rather queer idea occurred to me:

    Would would everyone think of a system whereby the user chooses a password when then enter their CC#. On the server, that password in encrypted using crypt() or some similar one-way encryption, and then the line of gibberish that is the encrypted password is used as the key for the encryption on the actual CC#. That way, the numbers can be stored on the server, while the keys aren't.

    Would something like this work?

    Spacewarp

    DISCLAIMER:
    Use of this advanced computing technology does not imply an endorsement
    of Western industrial civilization.
      Not really a secure option since if the code gets read you can figure out how to generate the key.

      Pete

      insert into pete values('red hair','near green eyes','overinflated ego');

      This would also not address the original problem of having automated, recurring transactions with no card-owner interaction. You can scramble the credit card numbers eight ways till Tuesday, but at some point, they must be unscrambled and sent to the bank.

Re: Encrypting Credit card numbers
by Starky (Chaplain) on Apr 23, 2001 at 11:59 UTC
    Per a previous suggestion, I would recommend to any of my customers who ask the same thing to consider simply charging credit cards as the numbers are submitted, thus avoiding the need to store credit card numbers in the first place. It will save you alot of paranoia and development and maintenance time.

    For one company I worked for, in which storing credit card numbers was seen as a hard requirement by the business types, here is what I did:

    1) https: Of course, credit card numbers must be submitted on a secure page. This is a no-brainer, but I thought I'd mention it for completeness.

    2) Encryption: Credit card numbers are stored by the application server in encrypted form in a database via GnuPG::Interface.

    3) Decryption: A separate transaction server, which is locked down tighter than, hee hee, well, real tight, has a daemon running that wakes up every 15 minutes. The daemon checks to see if there are any pending transactions, then (after various gyrations) decrypts the credit cards and submits the transactions, after which they are marked as complete.

    The key to this is that your private key(s) are on the transaction server. The transaction server has to be made the most secure box you can make, with every unnecessary process turned off and/or ipchains blocking everything except the database, transaction, and monitoring ports out and ssh in. In this particular company, which shall remain nameless, even the CTO was denied an account on the box. (He wasn't particularly astute or technically savvy, as I hear are many CTOs, and denying him an account definitely made waves, though I stuck to my guns.)

    I would also recommend reading up on the precise definition of a transaction (particularly 2-stage transactions) and model your transaction daemon on these specifications. All sorts of things can happen between beginning a credit card transaction and completing the transaction, and you should have status markers that indicate each step of the process as well as store every possible bit of information that goes back and forth. In light of the aforementioned caveat, you should also architect your daemon to be able to recover mid-stage through a botched transaction and proceed to completion. Everything from network outages to credit card processing server errors can cause a transaction to terminate unexpectedly, and accounting will at some point want you to be able to complete any partially completed transactions.

    Hope this helps!

      Rather than repeat what everyone else has been saying, I'll let some books do the talking for me... (Should be available from any good book store online or at your local book store)

      Bruce Schriner - Applied Cryptology, Second Edition Best cryptology book I've seen... discusses algorithims and security in general... ($60)

      Hacking Exposed 2 - (Insert authors here) Huge section on what not to do... ($40)

      Good luck
      Zak
        If you want to do serious cryptograpgy you should also check (IMHO)
        Cryptography : Theory and practice from Douglas STINSON.

        "Only Bad Coders Badly Code In Perl" (OBC2IP)
Re: Encrypting Credit card numbers
by AgentM (Curate) on Apr 23, 2001 at 19:42 UTC
    Here's a tip I haven't seen yet other than the post concerning Belgium- don't do it. Get someone else to do it for you- this someone will namely have more experience and resources to do exactly you need to do. Large ISPs have such services and you'll want to call business services with the credit card companies on how to hire a good service. While it may be pricey, keep in mind it's better than worrying about the precious credit card numbers yourself.
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
Re: Encrypting Credit card numbers
by Anonymous Monk on Aug 04, 2003 at 13:21 UTC
    Searching on the same subject..
    Currently I don't allow any CC number storage on my servers, but I have a client that want's to have them stored and then be able review over the web but not needing to automatically rebill.
    (trying to persuade the client to use external resource for cc processing like all of my other clients.)

    But..How does this sound...
    I'm a bit (very big bit) ignorant on the pgp system so be forgiving.

    Encrypt the CCnumber with one key and decrypt with another.
    The encryption would take place on the server in a perl script, and the result stored in a data file on the server
    The other key would not be on the server, it would reside on the remote clients pc.

    The decryption would be done in a java routine on the client pc when viewing the data via https:

    Any ideas on implementing this (pro's con's howto's?)

    Paul ASI
      I think a great company to have (albeit one that may not let you sleep much) would be one that held the card numbers for shmucks like myself that NEED them stored. You could set up the client to encrypt with the public key, send the info to you, and store it properly. When the info is called for, you can decrypt with the private key and process the charge as well. In essence you could run a payment gateway, but you hold the cards in encryption for each of your clients. To deal with the security on the client side, you simply let them design their own form with their own page design, but have it on your server inserting or posting as you please, secured how you want it. With this the card numbers couldn't get stolen (from the web merchant). The hacker could try and duplicate how the transaction is posted to the company holding the decryption key. But they wouldn't get the numbers. They could only run transactions through the merchant's account. Then guys like myself wouldn't even have access to my own client's card numbers, how great would that be! Not even me, as the CEO of a small web based business, could take a credit card number if I pleased. Of course one downside with owning a company such as this: every hacker and his grandma would see you as the Mecca of all credit card databases. I don't know, its 3 a.m., I'm not much of a programmer, I'm sure someone's thought of this before. If there's a company out there that does this LET ME KNOW, because I could use the service and wouldn't mind paying a percentage to ensure TOTAL and proper security of stored card numbers.
Re: Encrypting Credit card numbers
by roboticus (Canon) on Oct 01, 2009 at 18:45 UTC
    petethered:

    Check with your card processor. You can't help but break one or more rules unless you do so, as there are so many.

    PCI compliance is a "big deal" at the moment, and getting your software approved could be difficult (if possible at all). It may be that your processor has a solution on the shelf that may help you.

    Disclaimer: I don't know much about the front-end part of credit-card processing, but I do work work for a very large processor of credit card transactions.

    ...roboticus
Re: Encrypting Credit card numbers
by jdrago_999 (Hermit) on Oct 03, 2009 at 21:02 UTC

    Don't Encrypt, Don't Store

    If you go with a credit card processor like Verisign or Authorize.Net, you can just reference a previous authorization and tell them to re-bill the customer.

    The process works like this:

    1. Collect payment information.
    2. Authorize the payment through your gateway (Verisign, Authorize.net, etc).
    3. Get your authorization number.
    4. Store the authorization number.
    5. (Time passes, then it's time to re-bill)
    6. "Hey credit card company - charge the customer referenced by authorization # XYZ in the amount of $Y.YY"
    DONE!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://74455]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (17)
As of 2014-07-29 14:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (217 votes), past polls