这是我们用来存储 CC 详细信息的模型，这看起来有多安全？
我们所有的信息都使用公钥加密进行加密，密钥对取决于用户（它在服务器上生成，私钥是使用用户密码对称加密的，该密码也在数据库上散列）所以基本上在第一次运行时，用户发送他的密码通过 SSL 连接，密码与盐一起使用以生成 MD5 哈希，密码也用于加密私钥，私钥存储在服务器上。当用户想要付款时，他会发送他的密码。密码解密私钥，私钥解密抄送明细，抄送明细收费。
问问题
508 次
5 回答
4
如果用户的密码足够安全以保护私钥，为什么不跳过私钥并使用密码（通过合适的密钥派生算法）来加密信用卡号呢？不必要的并发症绝对不会提高安全性。
该方案不使用任何公钥，这表明非对称算法在这里不合适。
于 2010-03-16T20:50:11.257 回答
3
这将信用卡的安全性与用户密码的强度联系起来，用户密码的强度因用户而异，通常较弱。最好创建自己的对称加密密钥，确保其安全，然后做一堆专家发明的复杂东西，包括像 CBC、CTR 和 IV 这样的缩写。
于 2010-03-16T20:22:31.820 回答
1
我不确定您是否将卡号和私钥文件存储在一起。如果加密的私钥文件可用，似乎只需使用用户密码加密私钥文件，您就为字典式攻击打开了大门。
不知道为什么要使用可能很慢的公钥加密。此外，每个用户 1 个密钥对的模型可能无法扩展（有多少文件，您可以为公钥操作生成参数）。请注意，您可能有虐待行为——人们检查他们的被盗卡清单是否正确。
当用户不存在时，您仍然可以通过添加您自己的主密钥并从组合中派生密钥计划来防止任何使用卡号。一般来说，大多数商户不能遵循这个严格的要求，因为当用户不在场时使用卡号是有效的。
如果您只想要用户特定的密钥（并且每次都必须使用不同的 IV），那么您可以使用 openssl EVP_BytesToKey 路由并每次使用将派生加密密钥和 iv 的主密钥传递不同的盐（以及对于每个用户，它们会有所不同）。
最后，支付工具的使用仅受所描述的用户密码保护。一些用户选择弱密码。因此，您可能需要使用额外的证明来确保卡属于用户 - 其中一些是为了您自己的利益，因为您可以对抗友好的欺诈退款并保持您的真实欺诈退款较低。
于 2010-03-17T21:38:36.387 回答
0
我同意埃里克森的观点，即如果不使用公钥，则进行非对称加密毫无意义。
与往常一样，这里的问题是密钥管理问题。不安全性源于不知道如何安全地隐藏解密数据的密钥。
我不确定这是否可能，但如果您负担得起，请购买硬件安全模块并让您 HSM 管理密钥，或使用 HSM 主密钥加密所有客户（私有）密钥。
如果你不能，你应该找到一个合适的地方来存储你的“主”密钥，一个可能的例子是 windows 商店（如果有可能的话）。但是，我最承认我真的不知道 Windows 商店的安全性。
于 2010-03-16T21:03:49.810 回答
0
您可能想看看支付卡行业“支付应用程序 DSS”” https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
它可能有助于为您做出一些决定。
于 2010-03-22T17:21:19.857 回答