我的业务要求迫使我在短时间内存储客户的完整信用卡详细信息(编号,姓名,到期日期,CVV2).
理由:如果客户打电话订购产品并且他们的信用卡被当场拒绝,您很可能会失去销售.如果您了解他们的详细信息,感谢他们的交易,然后发现该卡被拒绝,您可以给他们打电话,他们更有可能找到另一种支付产品的方式.如果信用卡被接受,您可以清除订单中的详细信息.
我无法改变这一点.现有的系统以明文形式存储信用卡详细信息,而我正在构建的新系统中替换它,我显然不会复制这个!
那么,我的问题是如何在短时间内安全存储信用卡.我显然想要某种加密,但最好的方法是什么？
环境:C#,WinForms,SQL-Server.
基本上避免一直承担责任将CC细节保存在您身边,但是我可以假设您使用第三方服务进行交易,例如PayPal/Verisign或其他任何事情,其中大部分都有API,可以让您节省CC在他们身边的凭证,他们会给你一个密钥,然后你可以用它来完成或启动交易,所以他们负责处理困难的部分,而你所要做的就是将这个字符串密钥存储在你的数据库中.
我认为存储CVV信息(从某种意义上说它违反任何法律)实际上并不违法,但它确实违反了支付卡行业规则,并且可能会施加任何数量的不同制裁.所以,你的要求实际上可能导致你无法接受信用卡;-(
安德鲁,你需要了解PCI-DSS,这不是一项小任务.就个人而言,我觉得它非常模糊,但这是我所理解的.
首先,从您描述的方案中我将尝试授权卡的全额,然后如果失败,我会存储客户的信息(但不是持卡人数据),以便有人可以联系用户.在我工作的地方,我们的一些客户只收取1.00美元,然后立即使交易无效,只是为了确保卡有效.然后他们会手动处理所有订单.
您需要存储号码的地方是成功授权.您需要的唯一号码是信用卡号和交易代码(至少我曾经使用过的每个网关).
上次我查看它的标准并不是特定于加密算法,而是明确表示它应该是当前不可破解的加密.
现在,您不能做的一件事是在授权后存储CCV.我的理解是,您可以在授权之前存储它,但我永远不会得到任何人将其写入.基本上,你授权卡,你最好擦拭它.
而且在这一点上并不违法,但如果你被钉死,他们会把锤子砸在你身上.他们有权对你进行巨额罚款,但看起来他们通常做的就是让你进行补救.如果你不遵守,我不知道会发生什么,因为我听到这一切的每个人都遵守了.但是他们真的用显微镜上升了你的战利品.
最终,我相信他们真正拥有的唯一一个就是阻止你接受信用卡.我与之合作过的大多数商人都被吓死了.
如果您要存储信用卡信息,您确实需要符合PCI标准,否则您只是在寻找麻烦.
说过看看SQL Server 2005及更高版本中可用的单元级加密.巧合:)我最近在这里提供了一个关于使用SQL Server 2005/2008进行加密的T-SQL样本的演示文稿:http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip(链接位置已更新) 2008年12月23日)
如果您只想将字符串存储在内存中一小段时间,可以查看System.Security.SecureString.
取自这个答案:
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);
}
它需要在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/
上面的链接提供了一些有关成为合规的相关成本的良好信息.我们有客户要求我们存储信用卡号码,我们不会这样做,因为我们也可能被罚款.不好.不要让自己承担责任.
编辑:
此外,如果您决定存储信用卡信息,您肯定需要考虑您将要使用的加密形式.对称？不对称？
如果您执行对称加密(密钥),那么如果具有密钥(需要加密)的服务器(站点)以任何方式受到威胁,您就会面临一些严重的安全漏洞.请记住,即使编译代码也不会隐藏文本键.
如果您使用非对称加密(公共/私有密钥对),那么您会遇到一些其他问题,但如果主要面向公众的服务器受到威胁,他们将只拥有公钥,如果他们也访问您的数据库......他们将不会能够删除内容.
那么问题是,你在哪里存储私钥？在运行管理功能时,是否有人将其粘贴到本地计算机上..有一个单独的应用程序在桌面上运行以查看订单等.
有很多事情需要考虑.
最后注意事项:使用支付网关(Element Express,Authorize.NET,Paypal等),不要在本地存储任何信用卡信息.:P
以下是在C#中使用X509非对称加密的链接:http: //www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html
同意如果可以的话,应该避免存储数据.但也许你是第三方？如果是这样,请熟悉PCI标准.在网站上查看一下,您将找到需要实施的安全措施.
京公网安备 11010802040832号 | 京ICP备19059560号-6 