8

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

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

编辑：我在英国，我知道只要三位数的 CVV 号码从未被存储，我们就可以存储加密的信用卡详细信息。并感谢大家的好评。

4

10 回答 10

24

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

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

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

于 2008-09-03T06:02:00.323 回答
12

没关系。

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

重要的是身份验证代码。

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

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

除非您是收购方，在这种情况下，您应该询问一位资深的 unix 程序员/db2 人员。

“你不能把它本地存储在客户端的 cookie 中吗” <-- 永远

于 2008-09-04T08:40:19.687 回答
7

我想补充一下，除非你有一个非常好的理由，否则你不应该存储它们，并且将它们存储在 cookie 中是一个非常糟糕的主意——它们太容易掌握了（什么如果有人窃取了 cookie，就会发生这种情况——那么它的加密程度就无关紧要了）。

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

真的，只是不要这样做！

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

于 2008-09-04T09:24:39.393 回答
5

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

于 2008-09-03T06:13:37.723 回答
1

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

  • 加密短字符串，
  • 具有已知子串

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

于 2008-09-05T00:30:29.013 回答
1

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

无关紧要。

于 2008-09-06T16:04:52.860 回答
0

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

于 2008-09-03T05:48:20.170 回答
0

还有法律方面需要考虑。我不知道其他地方的情况，但在德国，您根本不允许存储信用卡号码1)。时期。是否加密它们以及以什么格式存储它们都没有关系。

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

1)除非您是联邦认证的信用卡机构。

于 2008-09-04T09:00:11.450 回答
0

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

在存储信用卡信息之前，您应该考虑一两次，因为做错的法律费用可能会很昂贵。

于 2008-09-04T09:10:25.667 回答
0

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

像 PHP 的 openssl_seal 之类的东西，不过如果你想使用不同的算法。

于 2011-01-22T07:24:11.003 回答