是否有用于信用卡加密的最佳 .NET 算法?
Posted
技术标签:
【中文标题】是否有用于信用卡加密的最佳 .NET 算法?【英文标题】:Is there a best .NET algorithm for credit card encryption? 【发布时间】:2010-09-07 15:50:30 【问题描述】:.NET System.Security.Cryptography
命名空间有一个相当令人困惑的算法集合,我可以使用这些算法来加密信用卡详细信息。哪个最好?
对于相对较短的字符串,它显然需要安全。
编辑:我在英国,我知道我们可以存储加密的信用卡详细信息,只要永远不会存储三位数的 CVV 号码。并感谢大家的精彩回复。
【问题讨论】:
【参考方案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】:还需要考虑法律方面的问题。我不知道其他地方的情况,但在德国你根本不允许存储信用卡号码1)。 期间。无论您是否加密它们以及以什么格式存储它们都无关紧要。
您可能所做的一切(这里我指的是记忆,没有任何司法知识)是存储信用卡号的强哈希(SHA-256?)以及最后一个四位数字和帐号。是的,仅从这些信息中重建完整的数字是微不足道的。法律并不总是合乎逻辑的。
1)除非您是联邦认证的信用卡机构。
【讨论】:
【参考方案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 之类的东西,不过如果您想使用不同的算法。
【讨论】:
以上是关于是否有用于信用卡加密的最佳 .NET 算法?的主要内容,如果未能解决你的问题,请参考以下文章