Safely Storing sensitive data client side

Question

Back Story I work at a small-mid size company and we are reworking our customer facing accounting portal and my manager wants to make single click payment option with the Credit Card info stored in cookies on the end users computer. I'm not in love this the idea.... at all (in fact I'm still trying to change his mind). That being said I am trying to make it as secure as I can, I think I've got a way to minimize the risk, here it is:

using SSL for all exchanges

encrypt the data in a number of cookies that are stored locally having the cipher as a confirm password that must be entered each time. forcing the cipher to be strong, say 15+ mixed chars, and this is confirmed by checking a hash of it on the server.

I know that the major weak spot is the cookie info that is stored in a two way encryption, that said is this a reasonably safe way to store the info....

The Question How can it be improved using this basic method.

Please I know that there is going to be a lot DON'T DO IT! answers (if I was not asking, I would be one of them) so please be specific, you are preaching to the choir on this so be constructive in the negatives.

Edit - If you have a specific point that you think I can use in reasoning with my manager please share. (I've already brought up that we maybe legally responsible if the CC info is stolen from a cookie, and he said he would have a lawyer look that over)

Thank you.

Why are you doing it this away? Are you trying to avoid storing the credit card info on the web server to avoid that responsibility? — Marcus Adams, Aug 01 '12 at 18:39
That is his Idea, but I think that we would be responsible for it just looking for way to convince him and prepare if he will not be convinced. — webLacky3rdClass, Aug 01 '12 at 18:46

score 2 · Accepted Answer · edited Jun 20 '20 at 09:12

using SSL for all exchanges

Should be done no matter what solution you use, as long as credit cards/payment info is involved. As you probably know.

encrypt the data in a number of cookies that are stored locally having the cipher as a confirm password that must be entered each time. forcing the cipher to be strong, say 15+ mixed chars, and this is confirmed by checking a hash of it on the server.

I usually remember my credit card number, and I'd rather put that in (as I'm already intent on not disclosing it to anyone) than a long and complicated key that most customers would write down somewhere anyway.

Even if we aren't allowed to say "don't do it!" - why don't you ask us for good ways to dissuade your manager from taking this decision? ;-)

What makes you unwilling to store this server-side? It's not like Amazon stores my credit card info in a cookie. The basic idea is to store all user info on the server, and access it when a user has authenticated successfully (i.e. logged in).

Cookies are in this case used to persist the logged in-state between browser sessions. The info this logged in-session has access to is stored on the server. With credit card info this usually entails a lot more security than other sensitive info, but it's the same basic idea.

Storing actual credit card numbers in cookies (encrypted or not) could be a potential PR nightmare when some tech-savvy customer realises what you are doing.

Thread for more reading: What information is OK to store in cookies?

Edit: The more I read through this question the more dumbfounded I get. Does your manager even know what a cookie is? How it works? What the point of it is? Saying that you want to store credit card info in cookies is like saying you want to use shoes as a means to transport shoe-laces. He is actively and purposefully shooting himself in the foot for no reason whatsoever. What he wants to achieve can be achieve a lot easier with other, much safer techniques - without any loss in functionality whatsoever.

From an article linked by Scott Hanselman:

Storing Credit Cards

If you absolutely must store credit card data it should be stored in encrypted form.

There are various compliance standards (specifically CSIP and PCI) that vendors are supposed to follow that describe specific rules of how networks need to be secured and data stored. These rules are fairly complex and require very expensive certification. However, these standards are so strict and expensive to get verified for that it's nearly impossible for smaller businesses to comply. While smaller vendors are not likely to be pushed to comply, not complying essentially releases the credit card company of any liability should there be fraud or a security breach. In other words you are fully responsible for the full extent of the damage (realistically you are anyway – I'm only echoing back the rough concepts of these certifications).

(my emphasis)

that was kinda what I was looking for, but it edit the Q to make it clear. — webLacky3rdClass, Aug 01 '12 at 13:52
the amazon bit is to give the "one click buy" idea, but thanks. — webLacky3rdClass, Aug 01 '12 at 13:58
Indeed - and my point is that "one click buy" is in no way reliant on storing customer info in cookies (or session). — Anders Arpi, Aug 01 '12 at 13:59
He is a hobby programmer, so he has enough knowledge to be dangerous. I think that last snippet will get his attention, I was telling him that before but coming from someone else that is more in the know about Card processing may help my case, Thanks. — webLacky3rdClass, Aug 01 '12 at 19:15
Thanks for the points, thanks for the link I think he is convinced. — webLacky3rdClass, Aug 02 '12 at 13:51

Matt · Answer 2 · 2012-08-01T14:47:48.970

1

Point out that Cookies are transmitted across each request. If you store credit card information in them not only is it less safe, but you are not actually gaining any sort of realistic time benefit. Outside of being easier to implement, there is no reason to do it this way. Since you're the one implementing it he shouldn't care about the ease of implementation anyway...

Edit: You could also point out that if anything goes wrong, he will be the one getting fired for it. Threatening his job is a great way to get him to see it your way.

edited Aug 01 '12 at 14:47

answered Aug 01 '12 at 14:29

Matt

265
2
3
10

I like the edit, but he is part owner, he is not going anywhere. – webLacky3rdClass Aug 01 '12 at 14:35

Marcus Adams · Answer 3 · 2012-08-01T19:18:17.910

0

Don't use the user's password as the key, or at least, it shouldn't be the only thing that comprises the key. You should encrypt the credit card account information with a private key that is stored on the server (and not known to the user).

You can decrypt the credit card information on the server, even though it's stored on the client. This way, there is no way for the encrypted credit card information to be reversed on the client (without knowing the private key).

You might encrypt the credit card account information with both the private key and the user's entered password, that way, they can't be sent to the server to be decrypted without the proper password.

edited Aug 01 '12 at 19:18

answered Aug 01 '12 at 19:12

Marcus Adams

53,009
9
91
143

What I'm worried about is that someone gets malware and it copies cookies to mine personal info and then they have the card info, they may not know it, but if they did they would be able to take there time cracking it. Is there some way of knowing if that has happen, so that the user can be alerted? (this maybe a question on its own not sure) – webLacky3rdClass Aug 01 '12 at 19:23
@Vaughn, With a sufficiently strong key and encryption algorithm, they're not going to crack it anytime soon. – Marcus Adams Aug 01 '12 at 19:43
encrypting with password is not a good idea because when the user changes their password, they are locked out of their own data since the old data can't be decrypted with the new password, and they may not know the old password anymore. – Lawrence Weru Mar 25 '17 at 19:45

Safely Storing sensitive data client side

3 Answers3

Linked