关于存储信用卡详细信息的安全模型的思考

Question

这是我们用来存储CC详细信息的模型，它看起来有多安全？

我们所有的信息都使用公共密钥加密进行加密，并且密钥对取决于用户（在服务器上生成的信息和使用用户密码对称加密的私钥也使用哈希在数据库中加密），因此基本上在首次运行时，用户发送通过SSL连接的密码，密码与添加盐一起使用以生成MD5哈希，密码也用于加密私钥，并且私钥存储在服务器上。 当用户想要付款时，他发送密码。 密码解密私钥，私钥解密CC详细信息，并收取CC详细信息。

Answer 1

如果用户的密码足够安全以保护私钥，为什么不跳过私钥并使用密码（通过适当的密钥派生算法 ）来加密信用卡号呢？ 不必要的并发症肯定不会提高安全性。

该方案不使用任何公共密钥，这表明此处使用了不对称算法。

Answer 2

这将信用卡的安全性与用户密码的强度联系在一起，用户密码的强度因用户而异，通常较弱。 最好先创建自己的对称加密密钥，并保持安全，然后再进行专家发明的一堆复杂的事情，包括CBC，CTR和IV等初始化 。

Answer 3

我不确定您是否将卡号和私钥文件存储在一起。 似乎仅通过使用用户密码来加密私钥文件，就意味着如果加密的私钥文件可用，就为字典式攻击打开了大门。

不知道为什么要使用公钥加密，这可能会很慢。 同样，每个用户1个密钥对的模型可能无法扩展（可以为公共密钥操作生成多少个文件参数）。 请注意，您可能有虐待行为-人们会检查被盗卡列表是否正确。

通过添加您自己的主密钥并从组合中得出密钥时间表，您仍然可以在不存在用户时阻止使用任何卡号。 通常，大多数商家不能遵循此严格要求，因为在用户不在时确实需要使用卡号。

如果只需要用户特定的密钥（并且每次都必须使用不同的IV），则可以使用openssl EVP_BytesToKey路由，并每次使用将从其派生加密密钥和iv的主密钥传递不同的密码。对于每个用户，它们将有所不同）。

最后，付款工具的使用仅受所述用户密码保护。 一些用户选择弱密码。 因此，您可能需要使用其他打样来确保卡属于用户-其中一些是为了您自己的利益，因为您可以与友善的欺诈扣款抗争，并降低真实的欺诈扣款。

Answer 4

我同意埃里克森的观点，即如果不使用公钥，那么进行非对称加密是没有意义的。

与往常一样，这里的问题是密钥管理问题。 不安全性源于不知道如何安全地隐藏用于解密数据的密钥。

我不确定是否可行，但是如果您负担得起，可以购买硬件安全模块，然后让HSM管理密钥，或者使用HSM主密钥对所有客户（专用）密钥进行加密。

如果不能，则应该找到一个合适的位置来存储“主”密钥，一个可能的示例是Windows存储（如果可能的话）。 但是，我最承认我并不真正知道Windows存储的安全性。

Answer 5

您可能需要看一下“支付卡行业”的“支付应用程序DSS”” https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

这可能有助于您做出一些决定。