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