2

I'm not a security guru. I'm thinking about how to implement credit card storage in a software system where credit card transactions are accepted through the web, but are manually executed by an in-house user. We are going to use HTTPS which (I believe) will eliminate the risk of a man-in-the-middle attack. Now, I'm trying to figure out if I can make it so that the data received from the client can encrypted before it hits our server.

The idea is that their browser would encrypt the data using the public part of an asymmetric key pair. The private part would be known by an in-house user. Then when it's time to manually process the charge, that user would go to an HTTPS page that we serve. They would manually enter the private key (which would not be transmitted to our servers) and the encrypted credit card info would be retrieved from our system and decrypted by the browser.

In this way I'm hoping I can keep any of our servers from ever seeing unencrypted credit card information. Am I missing some well known security hole? I've read this which seems to address a different kind of security hole. I've also read a few other SO questions, but none of them seem to map clearly to this particular design.

Edit #1: @Pointy asked why not use the industry standard. Major online retailers use solutions that are far more sophisticated and expensive than my problem warrants. Major retailers automatically process their transactions so typically work toward PCI-DSS compliance. This is not the problem that I'm trying to solve. I'm working on automatic tools to securely assist in manual transaction processing.

Edit #2: @Jason Dean pointed out that I didn't describe the plan for managing the private key very well. The idea is literally to have our employee keep it on a piece of paper at their desk. Our main concern is with remote security violations. Our physical site is secure enough that we're not worried about someone breaking in. The idea would be to keep the private key out of any persistent storage on any machine anywhere that way no purely electronic attack could possibly get both the data and the private key.

Spina
  • 8,986
  • 7
  • 37
  • 36
  • Why do you want to encrypt it on the client? – epascarello Oct 23 '12 at 19:41
  • Perhaps you should go about this by investigating the best practices of major reputable online retailers. – Pointy Oct 23 '12 at 19:49
  • 1
    @epascarello Encrypting it on the client would mean that the server never sees unencrypted credit card info. This means that it can't be accidentally disclosed (for example in system logs). – Spina Oct 23 '12 at 19:59
  • 4
    Just FYI, you are actually required to follow the PCI standard if you want to have anything to do with storing credit card information... http://stackoverflow.com/questions/13013686/storing-credit-card-details-with-mcrypt-or-gnupg/ – deceze Oct 23 '12 at 20:04
  • 1
    I think you may be trying to find a solution for a problem that doesn't exist. As @deceze said, you'd still need to be PCI compliant to transmit the credit card numbers, even in encrypted for. – Jason Dean Oct 23 '12 at 21:59
  • "The idea is literally to have our employee keep it on a piece of paper at their desk." Wow, that's an awful idea. Didn't you read my answer? BTW, do you know how long an Asymmetric crypto key is? It sounds like you are planning to make the poor saps you work with type it in. That is madness. – Jason Dean Oct 24 '12 at 17:00
  • 1
    Also unless you have red teamed your physical site extensively I would hesitate to say that it is "secure enough." People are the weakest link of any security system and you are introducing them into an area in which they are not needed, which opens up a whole host of phishing vulnerabilities that there is no way to guard against. – Daniel Sellers Oct 24 '12 at 18:06

2 Answers2

2

They would manually enter the private key (which would not be transmitted to our servers) and the encrypted credit card info would be retrieved from our system and decrypted by the browser.

It would be harder to keep secure and type in (or copy/paste) the private key than it would be to simply type in the credit card number. I would call this a rather obvious mistake in your scheme. Note that security protocols are hard, and as you are "not a security guru" I would strongly discourage you of trying to think one up.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • While I'm not a security guru, I am intelligent and interested. Honestly, this is mostly a thought experiment. Our initial implementation will be something that is much more standard. My question is intended to explore an idea in security that seems to solve a requirement that isn't commonly discussed. I've updated my question. – Spina Oct 24 '12 at 12:53
  • Anything is good as a thought experiment. You should not experiment with other persons credit card numbers though. – Maarten Bodewes Oct 26 '12 at 18:16
1

It's interesting that you are so concerned about the unencrypted data being seen by the server, but your willing to give the decryption key for all of that important to whatever $8/hour monkey you decide gets to type (or more specifically copy and paste) asymmetric keys all day.

Where do you plan to store these keys so that your monkey can get to them for copy/pasting? They'll need to be in plaintext for that.

Key management is, without question, the hardest thing to do in cryptography and you are talking about violating best practice protocols by making the key available to users that should not need it and by storing it insecurely.

SSL already takes care of encrypting your data before it leaves the client, then, when it reaches the server, you need to encrypt it again before storing it. You can use asymmetric crypto for that if you really want to. I would not worry about trying to do it at the client.

I think you are making things way harder than they need to be and with no benefit for your effort.

Jason Dean
  • 9,585
  • 27
  • 36
  • I've added details to the question (see edit #2) that further explain how we would manage the private key. – Spina Oct 24 '12 at 13:04