SitePoint Sponsor

User Tag List

Results 1 to 15 of 15
  1. #1
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Rome
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Asymmetrical security

    Hi everybody,
    I swear:

    IT'S NOT THE SAME OLD THING ABOUT CREDIT CARDS STORING
    I searched long in other threads about my peculiar issue but...

    I'm looking for a way to store credit cards data on a DB server. Before you kill me take a look at what follows:

    - This is the workflow: a registered user reserves a resource, the (registered) owner gets his CC data, even after months the user uses the resource and pays or the owner charges for a 'no show' fee.
    - We must store the credit card since owner doesn't charge it as soon as he gets the reservation
    - Encrypted mailing is not suitable for this situation since the system should manage even hundreds of affiliates and tech support for installing mail clients GPG plug-ins is too expensive or, at least, not inviting compared to the (unsecure, I know) standards in the typical online reservation business.
    - I though a solution could be encrypting with public key at the moment of reservation and letting affiliate view his data decrypting those with his own private key.
    - BUT private key should be stored on the server, since downloading data and decrypting with an offline software is not suitable for the same reason e-mail clients plug-in are.
    - I know we can have decryption set with private key + password (http://www.sitepoint.com/forums/showthread.php?t=256419), so this could be the solution: I can use the normal affiliate web password to login into his own control panel to have CC data decrypted. He'd have to insert that password anyway.

    While it seems to me the perfect solution I fear my (eventual ) unawareness of possible side-effects of this technique. For example: storing password in session variable after login, to later use it to decrypt CC data, is unsecure even if we are using a secured server in a trusted server farm?

    Thank you in advance, hope having been clear.
    Jacopo

  2. #2
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Several dual key options are available. The first is to use two servers. Theweb server makes a request using the key from the database, the second server has the CC data encrypted. they only come together when needed.

    Another option is to place part of the other key in a cookie in the user's browser. They would have to retype a password to generate new key pair for a new browser.

    Legal disclaimer: I am no security expert. Take these suggestions with a pinch of salt.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #3
    SitePoint Evangelist jplush76's Avatar
    Join Date
    Nov 2003
    Location
    Los Angeles, CA
    Posts
    460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if I'm picking your post up right its sounding a little scary to me.. you're saying a user registers their credit card with you and that credit card number will be seen by hundreds of affiliates? If your customer knew that I'm sure they wouldn't be a customer for long.. what I would do, just thinking off the top of my head, would be do what marcus just suggested, keep the actual credit number either on a different server or a different partition on the box and only store a token of the CC number in your web app. IE 2238-3983-xxxx-xxxx so if your front end DB is compromised only the token slips out.

    I'd also probably set myself up as the central cc proccessing service, not giving the affiliates or anyone else access to my customers credit cards. I would process the card then have the affiliate set up a routing to their account, so they could hit "PROCESS" and I process the CC info, and deposit the funds into the affiliate account, this way the CC number is never exposed to a human through a browser or over the wire to just anyone, its only sent via SSL to the cc processing company.

    but that may not be an option for you
    My-Bic - Easiest AJAX/PHP Framework Around
    Now Debug PHP scripts with Firebug!

  4. #4
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Rome
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First, thanks both for answers.

    jplush76,
    Quote Originally Posted by jplush76
    credit card number will be seen by hundreds of affiliates?
    No, each affiliate only checks for CC data concerning his own business. I'm sorry for having been ambigous.
    Quote Originally Posted by jplush76
    only store a token of the CC number in your web app
    What this would be useful for?
    Marcus's advice is to store half GPG key in cookies, as far as I understand. That way no intruder could get the entire private key if not using the same browser affiliate uses.

    Thanks again, bye!

  5. #5
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You shouldn't store credit card data anywhere it can be accessed via a web interface and you shouldn't keep it a minute longer than needed.

    The webserver should be purged of CC numbers daily - that way there are never more than a handful lying around to be stolen. If you do need to keep them, store them offline on a properly secured machine (you have to think about physical access as well as firewalls & etc).

    You should never pass CC numbers on to a third party over whom you have no control. Your affiliates can charge your own business account and you can charge the customer's card.

    Basically, if you are unsure about any aspect of ecommerce, you're not ready. It's not fair to your customers and if something goes wrong your professional reputation will take a body blow.

  6. #6
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Rome
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    you shouldn't keep it a minute longer than needed.
    You can argue I'm aware of it from my first post.
    Quote Originally Posted by McGruff
    You should never pass CC numbers on to a third party over whom you have no control. Your affiliates can charge your own business account and you can charge the customer's card.
    If I could use my own business account there would be no problem at all, I could even use GPGed CC card mailing or any kind of easier asymmetrical security device.
    More, affiliates getting the needed CC data are authenticated and browsing in SSL mode: we have some control on them...
    Quote Originally Posted by McGruff
    Basically, if you are unsure about any aspect of ecommerce, you're not ready.
    There's no binary knowledge flag in people's brains: every day we should learn more. I think that's a more reasonable version of your statement.
    For this I thank you too.

    Jacopo

  7. #7
    get into it! bigduke's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    847
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Pardon me if I got some portions wrong but handing over "your" customer's CC data to an affiliate isn't such a good idea unless they have a strong legal binding to your terms and you have a legal backing just as good.
    Secondly, why are we talking about giving the information to another party when they could use a centralized billing system for which simply encrypting the cc info and storing it in the db should be enough. This is what jplush was referring to probably.

    How will centralized billing work?
    1. Affiliate logs into his account on your system.
    2. Affiliate sends a payment request to client via email.
    3. Customer simply activates the process by acknowledging to the email or logging into his secure account and authorising the transaction.
    4. Complete the transaction using some gateway of the affiliate's choice and bill the customer.

    IPN's work like a dream for such issues, you can withhold the "resource" for as long as the payment is not cleared.

    Using key combo for security is not such a good idea, the idea is NOT to send the data to the third party and yet keep the process as smooth as possible.

    I HAVE deployed systems where the CC info was stored in the db because the client wanted to process them as a CNP (Card Not Present) transaction. Ofcourse, all this was deployed on SSL and required authentication.

  8. #8
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jakuza
    every day we should learn more. I think that's a more reasonable version of your statement.
    Reasonable doesn't come into it. Learning is fine but you must not attempt to do this kind of thing for real until you know what you are doing.

    I've always wanted to try my hand at brain surgery but I can't just go out and experiment on people.

  9. #9
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One option that has not been mentioned yet and that could work very well is delayed capture. Most payment gateways will allow you to send a credit card number and store it for later billing, this is called "delayed capture" in the industry (AUTH_ONLY parameter with authorize.net), and it allows you to only authorize the credit card in a first step, then upon confirmation of validity and the funds being available (the card has been authorized), you receive a transaction number, and then further down the road that transaction number can be used by your application to ask the payment gateway to complete the payment ("capture" the funds), without needing the credit card number again. This would be an optimal solution as it doesn't require you to store any credit card numbers at all, your only restriction might be how long your payment gateway lets you wait between the auth and the capture, here's where your mileage may vary.
    Garcia

  10. #10
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Take a look at this
    http://www.merchantexpress.com/AIM-i...m#_Toc23316619

    Specifically PRIOR_AUTH_CAPTURE.

    Unfortunately, it looks like you have a 30 day limit; personally, I wouldn't want my CC available for charges 30 days after I have provided it to a merchant anyway (save recurring transactions, of course), so this is probably for protection of the consumer. Attempts to get around this limitation might land you in dangerous territory with Visa/MC regulations.
    Garcia

  11. #11
    SitePoint Enthusiast
    Join Date
    Jan 2005
    Location
    Rome
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    One option that has not been mentioned yet and that could work very well is delayed capture.
    I knew about this feature and I already used it once before, in spite of McGruff's know-it-all-or-nothing mood, but unfortunately it's not well-suited to my needs since the website owner doesn't have to and doesn't want to take charge of billing at all.
    The access to a payment gateway could only be possible on his own gateway while we have to build a place where to gather every client we (already) have and to put them in contact with the public (on the web). Every client (most of them are hotel owners) want and should have their own card management.

    Quote Originally Posted by ghurtado
    I wouldn't want my CC available for charges 30 days after I have provided it to a merchant anyway
    I understand well your point but it's not mine: the customer could reserve a double room in Mexico for the next summer, just an example, and we don't want him to get his card charged before he steps into the hotel the day of check-in. I'm sure you wouldn't want it too! But if the customer doesn't arrive at the hotel the day of check-in a penalty fee must be charged and that's the reason why we must get the CC number at the reservation time.

    Ghurtado, thanks for your pleasant and kind suggestion. If you have more after my comments let me know please.

  12. #12
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    in spite of McGruff's know-it-all-or-nothing mood,
    I had thought it was just myself that had noticed this, but apparently not.

  13. #13
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You are most welcome, be sure to let us know how you end up solving your particular situation.
    Garcia

  14. #14
    get into it! bigduke's Avatar
    Join Date
    May 2004
    Location
    Australia
    Posts
    847
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This just came to mind, in case you DO allow the customers to have their own card management, don't forget to authorize them to charge the one using their resource. I believe carrying out out a CNP transaction w/o authorization, even if you were a trusted source leaves you liable under the law for foul play.

    And coming to think of it, if the control panel runs on ssl you dont need the gateway's delayed capturing feature anyway. The info IS very secure. Reading out the encrypted data from the db would suffice. However, in this case try to make the process more abstract. eg. the hotel owner simply charges the card using his gateway without knowing the number as such. This takes us back to the "don't share info" mantra though.

  15. #15
    SitePoint Enthusiast ZainyFX's Avatar
    Join Date
    Apr 2005
    Location
    Sydney Australia
    Posts
    52
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if you are using cron to run the processing file
    a thought could be to store the encryption key in the command line of the cron

    i believe this is how modernbill does its credit card encyptions


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •