我正在编写一个系统，像往常一样，客户要求提供方便的“记住您的信用卡详细信息”选项。
我已经告诉他们，这很可能是不可行的。但是，我刚才确实有一个好主意（tm），看到加密中的好主意（tm）实际上是坏主意（tm），我想我会把它放在这里进行审查，看看可以打出什么洞通过这。
本质上，我正在考虑xor使用为每个客户生成的一次性便笺簿来处理信用卡信息以及一些消息签名。该垫作为 cookie 变量存储在客户端浏览器上。下次用户尝试进行购买时，pad 会被发送到服务器，如果服务器可以正确解码其加密数据，它会显示信用卡信息已被填写。（抄送信息实际上并未传回）。服务器永远不会将 pad 存储在内存或页面文件之外的任何内容中。事实上，我打算将 pad 发送两次：一次是在到达 CC 页面时（服务器检查它是否应该请求 CC 信息），一次是在 CC 提交时获取实际信息。
用户还将被告知他们的信息“部分存储”在他们的 cookie 缓存中，这意味着他们预计如果他们的 cookie 被刷新，他们的 CC 信息就会丢失。
让我知道你认为这个计划在哪里严重失败。
听起来很粗略，我很确定你误用了“一次性垫”这个词。
与其走这条路，不如考虑使用 Authorize.net 的Customer Information Management之类的服务。基本上，你给他们卡信息，他们给你一个 ID，你可以用它来为卡充电。该 ID 与网站的商户帐户相关联，不能用于向任何其他商户充值。
它要安全得多，并且应该得到相同的结果。
注意：我不支持 Auth.net 或其 CIM。这只是我最熟悉的例子。
我认为，在客户端存储 pad 会使其容易受到 XSS 的攻击。
技术上：有缺陷。
法律上：可能有缺陷。和律师谈谈。
只有当该垫被安全保密时，一次性垫才有效。将其存储在 cookie 中绝对不能算作安全或机密（它是从服务器发送和从服务器发送的，它被放到用户的机器上，它可能是公共终端或共享机器）。这是一个非常糟糕的主意。这是一个聪明的想法，但最终非常有缺陷。我建议您阅读 PCI 合规性文档并做其他人做的事情（一般来说）：
如果信用卡存储在客户端，那么您将使用密钥存储它，这意味着它很容易受到攻击。
如果您正在存储信用卡服务器端，那么您不需要存储在客户端上的加密密钥的密钥。
如果您所描述的情况是这样一种情况，即用户不仅没有获得是否要存储其详细信息的选项，而且还需要重新填充它们而无需进行身份验证，这听起来像是一个非常危险的情况反正。如果我来到一家网吧并为我预先填写信用卡详细信息字段，我会非常高兴！