是否有用于信用卡加密的最佳 .NET 算法？答案

【问题标题】：Is there a best .NET algorithm for credit card encryption?是否有用于信用卡加密的最佳 .NET 算法？
【发布时间】：2010-09-07 15:50:30
【问题描述】：

.NET System.Security.Cryptography 命名空间有一个相当令人困惑的算法集合，我可以使用这些算法来加密信用卡详细信息。哪个最好？

对于相对较短的字符串，它显然需要安全。

编辑：我在英国，我知道我们可以存储加密的信用卡详细信息，只要永远不会存储三位数的 CVV 号码。并感谢大家的精彩回复。

【问题讨论】：

标签： .net security encryption cryptography

【解决方案1】：

3des 非常好，将盐存储在一边，并将标准密钥保存在数据库或配置文件之外的某个地方。这样一来，如果你被 pwned，他们就无法解密它。

【讨论】：

【解决方案2】：

无意冒犯，但这个问题有点“误导”。没有“银弹”解决方案。我建议一般阅读密码学，然后进行一些威胁建模。您应该问自己一些问题（绝不是完整的列表）：

进行加密的模块是需要解密的模块（在这种情况下使用对称加密）还是会将数据发送到将使用它的其他模块（在另一台机器上）（在这种情况下，您应该考虑公钥加密）
您要防范什么？有人访问数据库但没有源代码（在这种情况下，您可以将加密密钥直接硬编码到源代码中）？有人在嗅探您的本地网络（您应该考虑像 IPSec 这样的透明解决方案）？有人窃取了您的服务器（即使在数据中心也可能发生 - 在这种情况下应考虑全盘加密）？
您真的需要保留数据吗？不能直接传给信用卡处理商，得到确认后抹掉吗？您不能将其存储在客户端本地的 cookie 或 Flash LSO 中吗？如果将其存储在客户端，请确保在将其放入 cookie 之前在服务器端对其进行加密。此外，如果您使用 cookie，请确保将它们设为 http。
比较数据的相等性是否足够（即客户给我的数据与我拥有的数据相同）？如果是这样，请考虑存储它的哈希值。由于信用卡号相对较短且使用的符号集较少，因此应在散列之前为每个卡号生成唯一的盐。

稍后编辑：请注意，来自同一类别的标准加密算法（例如 3DES 和 AES - 都是对称块密码）具有相当的强度。大多数（商业）系统没有被破坏，因为有人暴力破解了他们的加密，而是因为他们的威胁建模不够详细（或者他们没有任何东西）。例如，您可以加密所有数据，但如果您碰巧有一个容易受到 SQL 注入攻击的面向公众的 Web 界面，那么它对您没有多大帮助。

【讨论】：

这有点晚了，但是：“另外，如果您使用 cookie，请确保您只将它们设为 http。”当然应该是 HTTPS / 安全 cookie 模式！

【解决方案3】：

根据PCI DSS 合规规则，任何行业领先的加密标准都足够了。因此，具有 256 位密钥的 3DES 就足够了（尽管可以使用其他标准）。看看这个http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

【讨论】：

具有 256 位密钥的 3DES？从来没有听说过。 AFAIK 3DES 仅支持最多 168 位，提供 112 位安全级别。

【解决方案4】：

没关系。

完整的卡号不应该接触磁盘。

重要的是验证码。

对于跟踪等，您将只使用最后 4 位 xxxx xxxx xxxx 1234 和到期日期。

如果您要存储卡号，则收单银行将强制选择加密方式。

除非你是收购方，在这种情况下你应该问一个老 unix 程序员/db2 人。

“你不能将它存储在客户端本地的 cookie 中吗”

【讨论】：

可以将完整的卡号写入磁盘。数据确实需要加密并具有网络防火墙，以防止机器直接访问 Internet。 PCI DSS 标准在标准的第 3 节中讨论卡数据。不过我同意你的看法，除非你必须，否则不要保留它。
他们不应该“触摸 [the] 磁盘”，但我们必须这样做。我们正在使用支付处理器，并且由于它们的工作方式（分离的身份验证和授权系统），我们必须简要存储 CC 编号，因为一旦我们从身份验证系统获得批准，我们就必须将其发送到授权系统。身份验证系统向用户显示信息，当它将控制权交还给我们时，我们在授权系统中重新开始。因此，我们必须存储信息，直到我们重新获得控制权。太疯狂了！

【解决方案5】：

还需要考虑法律方面的问题。我不知道其他地方的情况，但在德国你根本不允许存储信用卡号码¹⁾。 期间。无论您是否加密它们以及以什么格式存储它们都无关紧要。

您可能所做的一切（这里我指的是记忆，没有任何司法知识）是存储信用卡号的强哈希（SHA-256？）以及最后一个四位数字和帐号。是的，仅从这些信息中重建完整的数字是微不足道的。法律并不总是合乎逻辑的。

¹⁾除非您是联邦认证的信用卡机构。

【讨论】：

【解决方案6】：

提示：您应该调查存储信用卡号码是否合法。例如，在瑞典，您必须获得PCI (Payment Card Industry) 的认证，您的内部和外部安全性将在那里进行测试（还有很多其他事情）。

在存储信用卡信息之前，您应该三思而后行，因为做错的法律费用可能会很昂贵。

【讨论】：

【解决方案7】：

我要补充一点，除非你有一个非常好的理由，否则你不应该存储它们，并且将它们存储在 cookie 中是一个真的坏主意 - 他们'只需too easy 即可获取（如果有人窃取 cookie 会发生什么 - 那么它的加密程度无关紧要）。

如果您需要重复付款，大多数 CC 提供商会提供一种方法来执行此操作，即存储初始付款中的某种令牌，而不保留卡号（您可以只保留最后 4 位以显示给客户，以便他们知道存储了哪张卡）。

真的，只是不要这样做！

此外，您永远不应该保留 CCV 代码。

【讨论】：

如果您可以直接访问支付提供商，这很好——但对于离线处理，这将不起作用。

【解决方案8】：

不要忘记这里的完整性。当攻击者不知道密钥但可以操纵密文时，就会对开箱即用的加密进行伪造攻击。在以下情况下，这些可能会特别讨厌：

加密短字符串，
带有已知子串

信用卡正是如此。因此，在 CBC 模式下使用 System.Security.Cryptography AES 或 3DES 而不滚动您自己的校验和可能是危险的。阅读：没有密钥的攻击者有可能用另一个信用卡号替换一个信用卡号。

【讨论】：

【解决方案9】：

如果您使用的是第 3 方支付网关，则无需存储号码。

没有意义。

【讨论】：

【解决方案10】：

用公钥加密信用卡。仅将私钥提供给支付处理器机器。然后支付处理器机器可以查询数据库并完成工作，其他任何人，甚至添加条目的机器，都无法解密它。

类似于 PHP 的 openssl_seal 之类的东西，不过如果您想使用不同的算法。

【讨论】：