收集信用卡信息 - 并非收取付款
我正在 Linux 服务器上使用 PHP 和 MySQL 进行工作。
我有一个要求（我试图说服他们）从用户那里收集信用卡信息，以便我们公司可以使用卡号来保留酒店房间参加会议。我们根本不会自己给卡充值，而是将其发送到酒店。然后，我需要能够下载 CSV 文件，并且每次有人注册一封电子邮件以将所有信息发送给管理员。
我试图解释说这并不安全，但在我在这里工作之前，其他几位开发人员过去已经为他们这样做了。
我的问题是；有什么办法可以保证这个安全吗？如果没有，是否有任何第三方选项可以实现这一点？
编辑：
我感谢迄今为止发布的每个人，这只是让我越来越不想尝试这样做。如果您可以在答案中添加面向非技术人员的简单解释，我将不胜感激，事实上，网站源代码和链接将对我有很大帮助。我还没有找到任何网站可以以非技术方式解释这一点。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
首先，我不是律师。我之前曾多次实施过CC处理代码，但我只熟悉丹麦的法律和法规，因此您的情况可能会有所不同。
据我所知，您需要了解一些限制（来自 CC 提供商的法律和法规）。我不知道您在世界哪个地方，但在许多国家，您需要获得 PCI 认证才能处理信用卡数据，这是一个极其繁重、昂贵且持续的过程。
其他国家或州可能有通知规则，要求您在安全被破坏时支付通知持卡人的费用 - 除非您非常小心，否则这种情况并非不可能发生。
一般来说，我建议不要采用该程序。如果出现问题，您可能需要承担任何费用。
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.
存储卡的详细信息确实是一个坏主意。您将面临 PCI-DSS 审核带来的痛苦世界。它并不像“使用加密”那么简单，您需要制定适当的流程来安全地管理加密密钥、安排密钥轮换、安全地记录访问等等......存储卡详细信息绝对是您想要避免的事情。
如果您必须准备好一些东西，那么您（作为一家公司）最好的选择可能是从信用卡中将付款存入您自己的商家帐户，然后单独向酒店付款（从您的银行帐户/任何）。您充当客户向酒店付款的代理人。
大多数支付网关允许您安全地存储卡详细信息，并在以后收费（使用网关返回的令牌 ID），这在这里可能很有用。但您无法检索卡的详细信息以任何方式将其传递给酒店，这就是为什么您需要付款，然后单独向酒店付款。
但这仍然是一项艰巨的任务，因为即使采用这种简化的解决方案，PCI-DSS 的许多领域仍将发挥作用。
您询问过，所以这里有更多信息：
PCI-DSS 是支付卡行业数据安全标准。这是一套准则，基本上适用于任何“接触”持卡人数据（特别是卡号）的公司。从字面上看，触及它意味着对数据的任何处理，即使只是让它通过网络而不将其持久保存到磁盘上，也足以强制要求您必须遵守（尽管如果您不将详细信息保存到磁盘上，这会容易得多） ）
您尚未说明您位于世界的哪个部分，或者如何捕获这些卡详细信息（互联网/电话/亲自）。这些细节对于您如何实现合规性非常重要。
首先查看 PCI-DSS SAQ（自我评估问卷） 。这些 SAQ 是对不存储持卡人详细信息到磁盘的公司的最低要求，并且应该给人留下良好的印象，即需要在整个网络中实施的安全性以及应在整个网络中应用的策略。公司。
正如我所说，如果您正在考虑存储卡片详细信息，那么事情会变得更加复杂，因为作为一般规则，SAQ 不再足够好。您需要获得 QSA（合格安全评估员）的帮助，他将访问并就数据存储的最佳实践和其他各种发挥作用的问题提供建议。对于这种级别的合规性，您需要考虑年度审核（由 QSA 执行）和季度网络扫描。查看审核程序，详细了解所涉及的内容。特别要看看第 3 节，不要低估实现正确密钥的难度管理。
总而言之，完全遵守 PCI 要求的成本将非常高昂。即使对于已经拥有相当强大的安全策略的公司来说，引入 QSA 以及运行季度扫描和年度审核的成本也可能会花费数千美元。
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.
这是非常不安全的，我认为你反对它是正确的。也就是说...
一些想法：
酒店可以为您提供一个可以直接分发给用户的房价/团体代码吗？也许您甚至可以为他们提供一个直接进入酒店预订页面的链接，其中已填写代码。
除非您可以在支持 SSL 的网站上实现，否则不要考虑实现此操作。
不要在任何地方保存抄送号码，
只需生成电子邮件并扔掉
数出来。这使您不必担心大量非常困难的应用程序/服务器安全问题。
使用 GPG 加密电子邮件或
等效，以便它受到保护
传输且只能由预期收件人阅读。
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.
我建议您至少密切关注卡行业 PCI 合规性。 这里是一个 PDF 文档。
I suggest you follow the Card Industry PCI compliance closely at least. Here is a PDF document.
作为开发过此类系统的人，以纯文本形式存储任何信用卡信息是 100% 非法的。您必须加密所有数据，并且不允许您知道任何密钥。这是第 22 条军规，验证数据的唯一方法就是猜测，尽管听起来很悲伤。这就是意外充电发生的确切原因。
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.
正如其他人在这里所说的，存储信用卡信息需要您经过认证，这是事实。您可以要求提供信息来处理交易，但将其以任何形式存储是一个很大的禁忌。
幸运的是，authorize.net、braintree.com、paypal.com 等网站将允许您与他们的 API 进行交互，这样您就可以为您想要为其进行交易的每个实体获得一个“客户库 ID”。
这些第三方以 100% 合法的方式存储所有敏感信息。每当您想使用他们保存的信息进行交易时，您都可以使用他们的“Vault ID”与服务进行交互。
我使用过authorize.net、BrainTree 和PayPal。最近，BrainTree 取得了一些成功。我不会推荐 PayPal，除非您需要品牌知名度，或者您只是想进行直接转账，从而绕过询问他们任何类型的帐户信息（因为他们已经在 PayPal 中输入了该信息）。
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).
确保您的服务器尽可能安全并证明它尚未受到威胁。如果您的服务器受到威胁，这些都不会真正发挥作用。
在传输过程中使用 SSL 保护此信息。
收到后立即加密这些详细信息。这将有助于保护它静止时。如果可能，请使用密钥对的公钥对其进行加密，其中私钥（用于解密）不在位于您的服务器上。这很可能是您将此信息放入需要发送的电子邮件正文中，然后使用公钥加密（其中您的客户端拥有私钥）对正文进行加密。 （您可以在这里使用 PGP）。通过这种方式，数据在您的服务器上的存储时间尽可能短，然后一旦离开您的服务器，就只能由您的客户端访问。如果您使用对称加密算法，那么您的密钥也必然位于服务器上的某个位置（磁盘上、内存中等），攻击者可能会获取并使用该密钥来重新获得对详细信息的访问权限。
这本身并不是一种认可，但我之前在类似的情况下使用过它并取得了良好的结果： http://www.pgp.com/products/commandline/
请记住，安全漏洞总是存在，但通过这些步骤您将设置一个巨大的屏障来抵御攻击。我还可能补充一点，您可以从服务器的直接构建中研究像 Trip Wire 这样的系统完整性解决方案。当然，请确保所有密码都是强密码。
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.
Use SSL to protect this information during transit.
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.
如果您通过电子邮件发送文件，请务必在发送和接收计算机上使用安全连接（HTTPS / IMAP 或 POP3 over SSL、SMTP over SSL），并在发送前对文件进行加密。您也可以通过 OpenPGP 加密您的邮件和附件。另外，请确保两个邮件服务器（发送和接收）之间的安全，或者简单地使用相同的域来发送和接收电子邮件地址。不要使用 ZIP 文件或相关压缩容器的密码功能，因为它们通常在加密方面很弱。
如果您通过文件系统（即 USB 闪存盘）发送它，请务必使用加密的系统（即 TrueCrypt）。
确保有一台安全的计算机来进行下载和上传（进行下载/上传的加密分区、系统上没有间谍软件、密码系统、防火墙）。
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).