有没有最好的.NET信用卡加密算法?

没有冒犯,但这个问题有点“误导”。没有“银弹”解决方案。我建议通读密码学,然后做一些威胁建模。有些问题(决不是一个全面的清单)你应该问自己:

• 执行加密的模块是需要对其进行解密的模块(在本例中使用对称加密)还是将数据发送到将使用它的其他模块(在其他计算机上)(在这种情况下,应考虑公钥加密)
• 你想保护什么?有人访问数据库但没有源代码(在这种情况下,您可以将加密密钥直接硬编码到源代码中)?有人嗅探您的本地网络(您应该考虑像ipsec这样的透明解决方案)?有人窃取了您的服务器(即使在数据中心也可能发生这种情况——在这种情况下,应该考虑使用全磁盘加密)?
• 你真的需要保留数据吗?你不能直接把它交给信用卡处理机,在得到确认后再把它擦掉吗?你不能把它存储在客户端的cookie或flash lso中吗?如果将它存储在客户机上,请确保在将其放入cookie之前在服务器端对其进行加密。另外,如果您使用的是cookie,请确保只将其设置为http。
• 是否足以比较数据的相等性(即客户提供给我的数据与我的数据相同)?如果是这样,考虑存储它的散列值。由于信用卡号相对较短,并且使用了一组简化的符号,因此在散列之前,应该为每个符号生成一个唯一的salt。

后期编辑 :请注意,同一类别的标准加密算法(例如3DES和AES——都是对称块密码)具有相当的强度。大多数(商业)系统并没有被破坏,因为有人对它们的加密进行了野蛮的改造,但因为它们的威胁建模不够详细(或者完全没有)。例如,您可以加密所有数据,但是如果您碰巧有一个面向公共的Web界面,它很容易受到SQL注入的攻击,那么它对您没有太大帮助。

没关系。

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

最重要的是认证代码。

对于跟踪等,您只能使用最后4位数字XXXX XXXX XXXX 1234和到期日期。

如果您要存储卡号,密码选择将由收单银行授权。

除非您是收单机构,否则在这种情况下,应该会有一个老的Unix程序员/DB2人员来问您。

“您不能将它存储在客户端的本地cookie中吗”<--never

我想补充一点,除非你有一个很好的理由,否则你不应该把它们放在饼干里,而把它们放在饼干里是一种 真的? 坏主意-他们只是 too easy 去掌握(如果有人偷了一个饼干会发生什么-那么不管它有多加密)。

如果您需要重复付款,大多数CC提供商都会提供一种方法来实现这一点,即存储初始付款中的某种令牌,而不保留卡号(您只需保留最后4位数字以显示给客户,以便他们知道存储的是哪张卡)。

真的,别这样!

而且你永远不应该保留CCV代码。

按照 PCI DSS 符合规则,任何行业领先的加密标准都是足够的。因此,一个具有256位密钥的3DES就足够了(尽管可以使用其他标准)。检查这个 http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

别忘了这里的诚信。当攻击者不知道密钥,但可以操纵密文时,存在对开箱即用密码的伪造攻击。当出现以下情况时,这些问题尤其严重:

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

信用卡就是这样。因此,在CBC模式下使用system.security.cryptography aes或3des而不滚动您自己的校验和可能是危险的。阅读:没有密钥的攻击者可能会用另一个替换一个信用卡号码。

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

没有意义。

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

还有一些法律方面需要考虑。我不知道其他地方的情况,但在德国你根本不允许储存信用卡号码 ¹⁾ . 时期。 不管您是否加密它们,以及以什么格式存储它们。

你一切 可以 是吗(这里我指的是记忆,没有任何司法知识)是存储一个强大的哈希(sha-256?)信用卡号码,以及最后四位数字和帐号。是的,仅从这些信息中重建完整的数字是很简单的。法律并不总是合乎逻辑的。

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

提示: 你应该调查储存信用卡号码是否合法。例如,在瑞典,你必须通过 PCI (Payment Card Industry) 在这里,您的内部和外部安全性将得到测试(一段很长的时间,还有很多其他的事情)。

在存储信用卡信息之前,您应该考虑一两次,因为做错事的法律成本可能很高。

用公钥加密信用卡。仅将私钥授予支付处理器计算机。然后,支付处理器机器可以查询数据库并完成工作,其他任何人,甚至添加了条目的机器,都无法对其进行解密。

有点像php的openssl-seal,不过如果你想用不同的算法。