.NET System.Security.Cryptography命名空间有一个相当令人困惑的算法集合,我可以用它来加密信用卡详细信息.哪个最好？
对于相对较短的字符串,它显然需要是安全的.
编辑:我在英国,我知道我们可以存储加密的信用卡详细信息,只要从不存储三位数的CVV号码.并感谢所有人的回应.
没有冒犯,但这个问题有点"误入歧途".没有"银弹"解决方案.我建议一般阅读密码学,然后做一些威胁建模.有些问题(绝不是全面的清单)你应该问自己:
进行加密的模块是需要解密的模块(在这种情况下使用对称加密),还是将数据发送到将使用它的其他模块(在另一台机器上)(在这种情况下,您应该考虑使用公钥)加密)
你想要保护什么？有人访问数据库但没有源代码(在这种情况下,您可以将加密密钥直接硬编码到源代码中)？有人嗅探你的本地网络(你应该考虑像IPSec这样的透明解决方案)？有人偷了你的服务器(即使在数据中心也可能发生 - 在这种情况下应该考虑全盘加密)？
你真的需要保留数据吗？您是否不能直接将其传递给信用卡处理器并在收到确认后将其删除？你不能在客户端本地存储在cookie或Flash LSO中吗？如果将其存储在客户端,请确保在将其放入cookie之前在服务器端对其进行加密.此外,如果您使用的是Cookie,请确保仅将其设为http.
是否足以比较数据的相等性(即客户给我的数据与我的数据相同)？如果是这样,请考虑存储它的哈希值.由于信用卡号码相对较短并且使用减少的符号集,因此应在每次散列之前为每个符号生成唯一的盐.
稍后编辑:请注意,来自同一类别的标准加密算法(例如3DES和AES - 都是对称块加密码)具有相当的强度.大多数(商业)系统都没有被破坏,因为有人强化了他们的加密,但是因为他们的威胁建模不够详细(或者他们没有任何东西).例如,您可以加密所有数据,但如果您碰巧有一个易受SQL注入攻击的面向公众的Web界面,它对您没有多大帮助.
没关系.
完整的卡号不应该触摸磁盘.
重要的是授权代码.
对于跟踪等,您将只使用最后4位xxxx xxxx xxxx 1234和到期日期.
如果您要存储卡号,则加密银行将强制要求加密选项.
除非你是收购者,否则你应该问一个旧的unix程序员/ db2.
"你不能把它本地存储在客户端的cookie中"< - 永远不会
我添加到视图中,除非你有一个非常好的理由,否则你应该不存储它们,并将它们存储在cookie中是一个非常糟糕的主意 - 它们太容易被抓住(什么如果有人偷了一个cookie,那么就会发生这种情况 - 然后加密的程度并不重要).
如果您需要重复付款,大多数CC提供商将提供一种方法,通过存储初始付款中的某种令牌,而不保留卡号(您可以保留最后4位数字显示给客户)这样他们就知道存储了哪张卡.
真的,就是不要这样做!
此外,你永远不应该保留CCV代码.
根据PCI DSS合规性规则，任何行业领先的加密标准就足够了。因此带有256位密钥的3DES就足够了（尽管可以使用其他标准）。查看此http://pcianswers.com/2006/08/09/methods-of-encrypting-data/
京公网安备 11010802040832号 | 京ICP备19059560号-6 