Collecting Credit Card Information - not to collec

问题:

I am working in PHP on a Linux server with MySQL.

I have a requirement (that I have attempted to talk them out of) to collect credit card information from users so that our company can use the card numbers to hold hotel rooms for a conference. We will not be charging the cards ourselves at all, but instead just sending them to the hotel. I then need to be able to download a CSV file and each time someone signs up an email to go to the admin with all the information.

I tried to explain that this wasn't secure, but several other developers have done this for them in the past before I was working here.

My question is; is there anyway to make this secure? If not are there any third party options to make this happen?

---

EDIT:

I appreciate everyone who has posted so far, it has simply made me want to attempt to do this less and less. If you could add to your answers simple explanations, oriented at non-tech people, it would be greatly appreciated, in fact site source and links would help me a great deal. I haven't found any sites that would explain this in a non-tech way.

回答1:

It's really a bad idea to be storing card details. You're opening yourself up for a world of pain in the form of PCI-DSS audits. It is not as simple as 'use encryption', you need to have processes in place to securely manage the encryption keys, schedule key rotation, securely log access and so on and on... Storing card details is absolutely something you want to avoid.

If you have to have something in place, then the best option may be for you (as a company) to take payments from the credit cards to your own merchant account, then pay the hotels separately (from your bank account/whatever). You act as a proxy for the client making the payment to the hotel.

Most payment gateways allow you to store the card details securely, and charge at a later date (using a token id returned by the gateway), which will likely be useful here. But you wont be able to retrieve the card details to pass them through to the hotel in any way, which is why you would need to take payment, then organise a separate payment to the hotel.

Its still quite an undertaking though because a lot of areas of PCI-DSS will come into play even with this simplified solution.

You asked, so here is more information:

PCI-DSS is the Payment Card Industry Data Security Standard. It's a set of guidelines which basically apply to any company that 'touches' cardholder data, in particular the card number. Touching it literally means any handling of the data, even just having it pass through your network without it ever being persisted to disk is enough to mandate that you must comply, (though it is significantly easier if you don't persist the details to disk)

You didn't yet state which part of the world you're in, or how these card details are captured (internet/telephone/in person). These details are significant to how you can achieve compliance.

Start by taking a look at the PCI-DSS SAQ (Self Assessment Questionnaires). These SAQ's are the minimum requirements for companies that do not store cardholder details to disk, and should give a good impression of the security that needs to be in place across the network and policies that should be applied across the company.

As I said, if you're thinking of storing card details then things get more complicated, because as a general rule the SAQ is no longer good enough. You need to enrol the assistance of a QSA (Qualified Security Assessor) who will visit and advise on best practice for data storage and the various other points that come into play. For this level of compliance you're looking at yearly audits (carried out by the QSA), and quarterly network scans. Take a look at the audit procedures to get a detailed look at what is involved. In particular take a look at section 3 and do not underestimate the difficulty of implementing proper key management.

In summary, full PCI compliance will be very costly. Even for a company which already has pretty strong security policies the cost of bringing in a QSA and running quarterly scans and yearly audits alone will likely cost $thousands.

回答2:

First of, I am not a lawyer. I have implemented CC-handling code several times previously, but I am only familiar with Danish laws and regulations, so your mileage may vary.

As far as I know, there are restrictions in place (law and regulations from the CC providers) that you need to be aware of. I don't know where you are in the world, but in many countries you need to be PCI certified to handle credit card data and that is an extremely onerous, expensive and on-going process.

Other countries, or states, may have notification rules in play that requires you to pay the cost of notifying the card holder if security is broken - and unless you are very careful, it is not unlikely.

In general, I would recommend against that procedure. You may risk being liable for any costs if it goes wrong.

回答3:

This is very insecure and I think you're correct for opposing it. That said...

Some ideas:

• Can the hotel give you a rate/group code that you can disseminate to your users directly? Perhaps you could even give them a link that goes right to the hotel's reservation page, with the code already filled in.

• Don't even think about implementing this unless you can do it on an SSL-enabled site.

• Don't save the CC number anywhere, just generate the email and toss the number out. This alleviates you from having to worry about a ton of very difficult application / server security issues.

• Encrypt the email with GPG or equivalent so that it's protected in transit and can only be read by the intended recipient.

回答4:

I suggest you follow the Card Industry PCI compliance closely at least. Here is a PDF document.

回答5:

As someone who has worked on a system like this, it is 100% illegal to store any credit card information in plain text. You must encrypt all of the data and you are not allowed to know any piece of the keys. It is quite the catch 22, the only way to validate data is to guess as sad as that sounds. This is the exact reason why accidental charges occur.

回答6:

As others have said here, it's a fact that storing credit card information requires you to be certified. You can ask for information to process the transaction but keeping it on storage of any kind is a big no-no.

Fortunately sites like authorize.net, braintree.com, paypal.com, etc will let you interact with their APIs in such a way that you get a "Customer Vault ID" for each entity you'd like to make transactions for.

These 3rd parties store all the sensitive information in a 100% legit way. And whenever you would like to make a transaction using their saved information, you interact with the service using their "Vault ID".

I've used authorize.net, BrainTree and PayPal. Most recently it was BrainTree and had some good success with them. I would not recommend PayPal unless you need the brand recognition or you just want to do a direct transfer whereby you bypass asking them for account information of any kind (because they already entered it in PayPal).

回答7:

1. Make sure your server is as secure as possible and prove that it isn't already compromised. None of this will really work well if you have a compromised server.

2. Use SSL to protect this information during transit.

3. Encrypt these details immediately upon receipt. This will help protect it at rest. If possible, encrypt it with a public key for a key pair where the private key (used for decryption) is not on your server. This could easily be that you place this information into the body of the email that you're required to send, then encrypt the body with public-key encryption where your client has the private key. (You could use PGP here). In this way, the data is help on your server as briefly as possible, then once off your server, is accessible only by your client. If you use a symmetric encryption algorithm, then your key will necessarily also be on your server somewhere (on disk, in memory, etc.), which could be obtained and used by an attacker to regain access to the details.

This isn't an endorsement, per se, but I have used this before in similar situations with good results: http://www.pgp.com/products/commandline/

Remember that there are always security holes, but you'll be raising a large barrier against attacks with these steps. I might also add that you look into a system integrity solution like Trip Wire from the immediate build of your server. And of course, ensure that all of your passwords are strong.

回答8:

If you send the file via email, be sure to use secured connexions (HTTPS / IMAP or POP3 over SSL, SMTP over SSL) on both sending and receiving computers and have the file encrypted prior sending. You can encrypt your mail and attachment via OpenPGP, too. Also, ensure the security between the two mail servers (sending and receiving), or simply use the same domain for sending and receiving email addresses. Do not use the password-feature of a ZIP file or related comrpessing container, since they are usually cryptographically weak. If you send it on a filesystem (ie. USB pendrive), be sure to use a crypted one (ie. TrueCrypt).

Be sure to have a secured computer where the download and upload takes part (encrypted partition where the download/upload takes place, no spywares on the system, passworded system, firewalled).