Question

我的业务要求迫使我在短时间内存储客户的完整信用卡详细信息（电话号码，姓名，有效期，CVV2）。

理由：如果客户打电话订购产品并且他们的信用卡被当场拒绝，您很可能会失去销售。如果您了解他们的详细信息，感谢他们的交易，然后发现该卡被拒绝，您可以给他们打电话，他们更有可能找到另一种支付产品的方式。如果信用卡被接受，您可以清除订单中的详细信息。

我无法改变这一点。现有系统以明文形式存储信用卡详细信息，而我正在构建的新系统中替换此信息，我显然不将要复制此信息！

那么，我的问题是如何在短时间内安全存储信用卡。我显然想要某种加密，但最好的方法是什么？

环境：C＃，WinForms，SQL-Server。

Answer 1

基本上尽量避免将责任保存在您身边，但我可以假设您使用第三方服务进行交易，例如PayPal / Verisign等等，其中大多数都有API可以让您保存CC凭证，他们会给你一个密钥，然后你可以用它来完成或启动交易，所以他们负责处理困难的部分，而你所要做的就是将这个字符串密钥存储在你的DB。

Answer 2

我认为存储CVV信息（从某种意义上说它违反任何法律）实际上并不违法，但它确实违反了支付卡行业规则，并且可能会施加任何数量的不同制裁。因此，您的要求实际上可能导致您无法接受信用卡; - （

Answer 3

安德鲁，你需要了解PCI-DSS，这不是一项小任务。就个人而言，我发现它非常模糊，但这是我所理解的。

首先，从您描述的方案中我将尝试授权卡的全额，然后如果失败，我会存储客户的信息（但不是持卡人数据），以便有人可以联系用户。在我工作的地方，我们的一些客户只收取1.00美元，然后立即使交易无效，只是为了确保卡有效。然后他们会手动处理所有订单。

您需要存储号码是否成功授权。您需要的唯一号码是信用卡号和交易代码（至少我曾经使用过的每个网关）。

上次查看标准时，标准并不是特定于加密算法，而是明确表示它应该是当前不可破解的加密。

现在，您不能做的一件事是在授权后存储CCV。我的理解是，您可以在授权之前存储它，但我永远不会得到任何人将其写入。基本上，你授权卡，你最好擦拭它。

此时此刻并非违法，但如果你被钉死，他们会把锤子放在你身上。他们有权对你进行巨额罚款，但看起来他们通常做的就是让你进行补救。如果你不遵守，我不知道会发生什么，因为我听到这一切的每个人都遵守了。但是他们真的用显微镜上升了你的战利品。

最终，我相信他们真正拥有的唯一一个就是阻止你接受信用卡。我与之合作的大多数商人都被吓死了。

Answer 4

如果您要存储信用卡信息，您确实需要符合PCI标准，或者您只是在寻找麻烦。

说过看看SQL Server 2005及更高版本中可用的单元级加密。巧合的是:)我最近给出了一个关于使用SQL Server 2005/2008进行加密的T-SQL样本的演示文稿：http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip（链接位置已于2008年12月23日更新）

Answer 5

如果您只想将字符串存储在内存中一小段时间，可以查看System.Security.SecureString。

取自answer：

SecureString值以加密方式存储（非混淆），但最重要的是，它们永远不会交换到磁盘，并且可以在完成后立即处理。

它们使用起来很棘手，因为你一次只能构建一个角色（鼓励你通过在用户输入密码时捕获击键来构建它们），并需要三行代码来恢复然后擦除它们纯文本，但如果使用得当，它们可以通过避免虚拟内存漏洞使程序更安全。

在示例的最后，SecureString被转换为常规托管字符串，这使得它再次易受攻击（确保在完成后使用try-catch-finally模式将字符串置零）。 SecureString的用途是通过限制垃圾收集器对该值的复制数量来减少攻击的表面区域，并降低写入交换文件的可能性。

// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
   sPassphrase.AppendChar(input.KeyChar);
   Console.Write('*');
   input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();

// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
   IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
   string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
   // ... use the string ...
}
catch {
   // error handling
} 
finally {
   Marshal.ZeroFreeBSTR(ptrPassphrase);
}

Answer 6

它需要在30,000美元附近的某个地方才能合格并能够做到这一点。您最好使用第三方支付服务。就个人而言，我推荐Element Express，他们有一个“托管”解决方案，绕过PCI-DSS PAPDB合规性。我必须转换为我自己的应用程序，甚至是销售点机器！这是一个很大的痛苦，但我们是一家小公司。

http://www.elementps.com/software-providers/our-security-edge/hosted-payments/PA-DSS-Certification-vs-Elements-Hosted-Payments/

上述链接提供了一些有关成为合规成本的良好信息。我们有客户要求我们存储信用卡号码，我们不会这样做，因为我们也可能被罚款。不好。不要让自己承担责任。

编辑：

此外，如果您决定存储信用卡信息，您肯定需要考虑您将要使用的加密形式。对称？不对称？

如果您执行对称加密（Passkey），那么如果具有密钥（需要加密）的服务器（站点）以任何方式受到威胁，您就会面临一些严重的安全漏洞。请记住，即使编译代码也不会隐藏文本键。

如果您使用非对称加密（公钥/私钥对），则会遇到一些其他问题，但如果主要面向公众的服务器遭到入侵，他们将只有公钥，如果他们也访问您的数据库..他们将无法解密内容。

那么问题是，你在哪里存储私钥？您是否有人在运行管理功能时从本地计算机粘贴它。有一个单独的应用程序在桌面上运行以查看订单等。

有很多事情需要考虑。

最终说明：使用支付网关（Element Express，Authorize.NET，Paypal等），不要在本地存储任何信用卡信息。：P

以下是在C＃中使用X509非对称加密的链接：http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html

Answer 7

同意如果可以的话，应该避免存储数据。但也许你那个第三方？如果是这样，请熟悉PCI standards。在网站上查看一下，您会发现必需要实施的安全措施。

Answer 8

让我们看一下这个要求有点不同。目前它看起来像这样：

作为网站X的产品所有者，我希望系统暂时存储客户cc详细信息，以便我可以恢复被CC公司拒绝的销售

Ppl倾向于那样思考并以这种方式请求功能。现在我认为您的要求更方便地描述如下：

作为一个用户，我希望网站X能够为我的购买重试付款，所以我没有必须再次通过结账流程的麻烦因为这是一个真正的痛苦......

所以没有明确的要求存储任何东西（在你身边）是否存在？它唯一隐含的

付款服务提供商可以为您的商家帐户提供程序化API，并且可以尝试重新审核拒绝的尝试。我认为@bashmohandes在早些时候已经没过了

并非所有支付提供商都能做到这一点，但我认为这取决于他们与所涉银行的关系。那就是你要避免的东西，即。与银行关系密切。

场景1：假设我说的都是真的

除了对授权尝试的引用之外，您不必存储任何内容。有些支付提供商甚至会给你一个甜蜜的后台工具，所以你不必自己做重新认证。我认为paygate可以做到这一点

我认为最好的选择是采访一些支付服务提供商。他们应该像手背一样知道这些东西。这可能是零代码解决方案

场景2：假设我完全错了，但合法地存储CC的东西是好的

所以你必须暂时将这些数据存储在某处。我建议：

使用非供应商特定的双向加密方法（自然），以便您可以使用任何语言/平台加密/解密
将加密/解密服务与您的应用分离，并将其视为黑盒子
使用公钥/私钥对此服务进行身份验证
将此计算机置于具有自己的防火墙规则的专用网络上（不一定是硬件防火墙，但硬件更好）
让您的应用服务器通过ssl与本机通信（您可以使用自签名证书，因为它位于您的专用LAN上）

我在场景2中建议的只是障碍，但最终持久性赢得了比赛以获取您的数据。绝对保护数据的唯一方法是将服务器从以太网中拔出，但该选项有点激进： - ）

场景1会很好。不是吗？

Answer 9

考虑你的日志！

如果您向客户解释完整的影响（如果发现他们不符合要求的补救要求），那么请相信我，您的“业务要求”会很快发生变化。

如果你必须存储信用卡号码（我在这里提出你认为没有合理的情况），并打算使用内置的数据库加密，那么请考虑一下：那你的交易日志？

如果您的交易记录明确反映了信用卡号，那么您就不合规了，如果您被抓住，应该在您的网站上预算10,000到50,000美元的取证审核。如果您的客户起诉你，因为您应该知道所有这些内容，请为您自己的律师预算。

因此，如果您要存储信用卡号，请在代码中运行密码，以便事务日志（插入或更新）反映加密字符串，而不是明文中的卡号。

在您的数据库中甚至没有CVV加密的字段或列 - 加密与否 - 法务审计将揭示这一点（日志也是如此），然后您的客户处于大麻烦之中。他们将支付罚款，可能失去接受信用卡的能力。你的律师会非常高兴。

Answer 10

我有一篇博文，介绍了在数据库中存储敏感数据的确切情况。博文使用了我使用Triple DES算法构建的String Encryptor类，但如果您愿意，可以自行插入。

博客文章包含所使用的视频和源代码。您可以在http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.html查看。我认为这肯定会解决你的问题。

存储信用卡详细信息

10 个答案: