Security review: client credit card# stored on server but with one time pad encryption stored in client cookie.

Question

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.

Answer 1

Storing the pad client-side leaves it vulnerable to XSS, I would think.

Answer 2

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):

1. Don't do it.
2. Use a payment processor that will securely store the CC and handle billing (i.e. PayPal).
3. Setup a separate and strongly secured payment gateway, this machine only processes credit card transactions, and it in turn accesses a secured machine that stores the credit card data.
4. Remember that storing credit card numbers will basically violate PCI and will probably violate any merchant agreements and might even be illegal in your jurisdiction (privacy laws, etc.), consult a lawyer please.
5. Don't do it. Seriously. Find a payment processor who will handle this for you.

Answer 3

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!