安全审查：客户端信用卡# 存储在服务器上，但一次性加密存储在客户端 cookie 中
我正在编写一个系统，像往常一样，客户要求提供一个方便的“记住您的信用卡详细信息”选项。
我已经告诉他们这很可能是不行的。 然而，我刚才确实有一个好主意（tm），并且看到加密中的好主意（tm）实际上是坏主意（tm），我想我应该把它放在这里进行审查，看看可以打哪些漏洞通过它。
本质上，我正在考虑使用为每个客户端生成的一次性记事本来对信用卡信息和一些消息签名进行异或。 该 pad 作为 cookie 变量存储在客户端浏览器上。 下次用户尝试进行购买时，密码本会发送到服务器，如果服务器可以正确解码其加密数据，则会显示信用卡信息已被填写。 （抄送信息实际上并未传回）。 服务器绝不会将 pad 存储在内存或页面文件之外的任何内容中。 事实上，我打算将 pad 发送两次：一次是在到达 CC 页面时（服务器检查是否应该询问 CC 信息），一次是在 CC 提交时获取实际信息。
用户还将被指示他们的信息“部分存储”在他们的 cookie 缓存中，这意味着他们会期望如果他们的 cookie 被刷新，他们的 CC 信息就会丢失。
让我知道你认为这个计划在哪里严重失败。
I'm writing a system where, as usual, the client is asking for a convenience "remember your credit card details" option.
I've told them that this is in all likelihood a no-go. However, I did have a good idea (tm) just now, and seeing that Good Ideas in Encryption(tm) are actually Bad Ideas (tm), I thought I'd put it up for review here and see what holes can be punched through it.
Essentially, I'm thinking of xor'ing the credit card information plus some message signature using a one time pad that's generated per client. This pad is stored as a cookie variable on the client's browser.
Next time that user tries to place a purchase, the pad is sent to the server, and if the server can properly decode its encrypted data, it shows the credit card information as already being filled. (The cc info isn't actually transmitted back). The server will never store the pad in anything more than memory or page file. In fact, I intend to have the pad be sent twice: once upon arrival on the CC page (where the server checks if it should ask for CC information), and once on CC submission to get the actual information.
The user will also be instructed that their information is "partially stored" in their cookie cache, meaning that they will expect that if their cookies are flushed, their CC information is lost.
Let me know where you think this scheme is horribly failing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
听起来很粗略，而且我很确定您误用了“一次性便笺本”一词。
不要走这条路，而是考虑使用 Authorize.net 的客户信息管理。 基本上，您向他们提供卡信息，然后他们给您返回一个 ID，您可以使用该 ID 为卡充值。 该 ID 链接到网站的商家帐户，不能用于向任何其他商家对该卡进行收费。
它更加安全，并且应该会给您带来相同的结果。
注意：我不认可 Auth.net 或其 CIM。 这只是我最熟悉的例子。
Sounds sketchy, and I'm pretty sure you're misusing the term "one time pad."
Instead of going this route, look into using a service like Authorize.net's Customer Information Management. Basically, you give them the card info, and they give you back an ID that you can use to charge the card. The ID is linked to the website's merchant account, and can't be used to charge the card with any other merchant.
It's much, much safer, and should get you the same results.
Note: I'm not endorsing Auth.net or its CIM. It's just the example I'm most familiar with.
我认为，将 pad 存储在客户端会使其容易受到 XSS 攻击。
Storing the pad client-side leaves it vulnerable to XSS, I would think.
技术上：有缺陷。
从法律上来说：可能有缺陷。 与律师交谈。
一次性便笺簿只有在安全保密的情况下才有效。 将其存储在 cookie 中绝对算不上安全或秘密（它被发送到服务器或从服务器发送，它被放到用户的计算机上，这可能是公共终端或共享计算机）。 这是一个非常糟糕的主意。 这是一个聪明的想法，但最终是有很大缺陷的。 我建议您阅读 PCI 合规性文档并按照其他人的做法（一般来说）：
Technologically: flawed.
Legally: probably flawed. talk to a lawyer.
A one time pad only works if the pad is securely kept secret. Storing it in a cookie definitely doesn't count as secure or secret (it's sent to and from the server, it's dropped onto the user's machine, which might be a public terminal or shared machine). This is a really bad idea. It's a clever idea but ultimately very flawed. I suggest you read the PCI compliance documentation and do what other people do which is (generally speaking):
如果信用卡存储在客户端，那么您将其与密钥一起存储，这意味着它很容易受到攻击。
如果您存储信用卡服务器端，则不需要存储在客户端上的加密密钥的密钥。
如果您所描述的情况是用户不仅无法选择是否要存储其详细信息，而且还需要在无需进行身份验证的情况下重新填充它们，这听起来像是一种非常危险的情况。反正。 如果我来到一家网吧并为我预先填写了信用卡详细信息字段，我会非常高兴！
If the credit card is being stored client side then you're storing it with the key which means it's vulnerable.
If you are storing the credit card server side then you don't need a key of an encryption key stored on the client.
It sounds like a very dangerous situation if what you are describing is a case where the user is not only not being given the option whether or not they want to store their details but is also going to have them re-populated without having to authenticate in any way. I'd be pretty happy if I came along to an internet cafe and got the credit card details fields pre-populated for me!