.NETSystem.Security.Cryptography命名空间具有令人困惑的算法集合，我可以使用这些算法对信用卡详细信息进行加密。哪个最好？

显然，对于较短的字符串，它必须是安全的。

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

解决方案

回答

3des很好，可以将盐存储在一边，并在数据库或者配置文件中没有的位置保留标准密钥。这样，如果我们被伪装，他们将无法对其进行解密。

回答

没有冒犯，但问题有点"误导"。没有"银弹"解决方案。我建议一般阅读密码学，然后进行一些威胁建模。我们应该问自己一些问题(绝不是详尽的清单)：

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

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

回答

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

回答

没关系。

完整的卡号切勿接触磁盘。

重要的是验证码。

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

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

除非我们是收购方，否则我们应该问一个老的unix程序员/ db2.

"我们不能将其本地存储在Cookie中的客户端上" <-NEVER

回答

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

我们可能要做的所有事情(在这里，我是从内存中引用的，在没有任何司法常识的情况下)是存储信用卡号，最后四位数字和帐号的强哈希(SHA-256？)。是的，仅从这些信息中重建完整的数字是微不足道的。法律并不总是合乎逻辑的。

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

回答

提示：我们应该调查存储信用卡号是否合法。例如，在瑞典，我们将必须通过PCI(支付卡行业)认证，在那里将对内部和外部安全性进行测试(长期以来还会进行很多其他事情)。

在存储信用卡信息之前，我们应该三思而后行，因为这样做的法律成本可能很高。

回答

我认为，除非我们有充分的理由，否则不要简单地存储它们，并且将它们存储在Cookie中是一个非常糟糕的主意，因为它们太容易掌握了(发生了什么情况如果有人窃取了cookie，那么加密的程度就无关紧要了。

如果我们需要重复付款，大多数CC提供商会提供一种方法来存储初始付款中的某种代币，而无需保留卡号(我们可以保留最后4位数字以显示给客户)以便他们知道要存储哪个卡)。

真的，只是不要这样做！

另外，我们永远都不要保留CCV代码。

回答

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

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

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

回答

如果我们使用的是第三方付款网关，则无需存储号码。

无关紧要。