39

The company I work for needs a system to perform monthly credit card charges to customer accounts. Customers will be able to update their credit card information from an online interface written in PHP (which will be presented through HTTP over SSL). The monthly charges will be run manually through a password-protected admin area of the same interface, which will basically amount to a batch call to Authorize.Net's API.

My coworkers want to store the (encrypted) credit card information in a MySQL database. They plan to encrypt the credit card numbers with PHP's mcrypt extension, presumably using Rijndael/AES or Twofish. The subject of key management was glossed over, but the following two options were mentioned:

  1. storing keys in the database, with a separate key for each credit card entry; or

  2. storing a single encryption key for all credit card entries in a PHP file as a variable (similar to how PHP applications such as WordPress and MediaWiki store database credentials).

How can I convince them not to go this route? We will be using Authorize.net for payment processing, so I mentioned their Customer Information Manager service as an alternative to storing credit card information ourselves. However, I don't know the subject well enough to make a compelling argument (my arguments were "none of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner").

If I am unable to convince them to use a 3rd party service like Customer Information Manager, what should I keep in mind in order to keep customers' credit card information safe? In particular, how should I manage encryption keys? Should there be a separate encryption key for each customer entry? Where can I store the keys so I can decrypt the credit card information before sending the transactions over to Authorize.Net? The two options mentioned above don't seem very sound to me (but again, I don't know the subject well enough to make a compelling argument against either).

Update: I found someone in the company familiar with PCI DSS compliance, so I'm working with him to make sure this gets done right. However, I would still appreciate answers to my questions above (both to improve my knowledge and to help others in a similar situation).

Update 2: Success! Another developer sat down and read the PCI DSS guideline and decided that it's a bad idea to store the information ourselves after all. We will be using Authorize.Net's Customer Information Manager service.

Mike Pennington
  • 167
  • 1
  • 11
M8R-53mg86
  • 393
  • 3
  • 5
  • 19
    My first reaction is: are you [PCI DSS](http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard) compliant? If the answer is “no” or “I don't know”, you aren't allowed to store credit card numbers in many circumstances. – Gilles 'SO- stop being evil' Aug 14 '12 at 20:50
  • 8
    My first reaction was: "who do you work for, and can I cancel any accounts I may have with the company?" But in all seriousness, PCI DSS or similar will be a (usually costly) requirement if you want to store credit card details – Polynomial Aug 14 '12 at 20:58
  • 2
    Those answers aren't helpful, unfortunately. Even if my response to Gilles' question is "I don't know", my coworkers would mistakenly respond "yes". I need logical arguments, not appeals to authority. (Note that this billing system is *not* in place yet, so we're not currently breaking any rules. However, I want to prevent that from happening in the future.) – M8R-53mg86 Aug 14 '12 at 21:54
  • 5
    HOORAY! For Update 2! – David Stratton Aug 21 '12 at 20:40
  • just for the sake of completeness. Using AES does not mean "secure" out of the box. For instance: encrypting with AES in ECB mode is a very bad idea, albeit AES is a standard and is a specific version of Rijndael using ECB might bring you in trouble. – Samuel Dec 19 '13 at 12:15

4 Answers4

33

Storing card numbers means you must comply with the requirements of PCI-DSS, or you risk fines and breach of your merchant account contract. PCI-DSS has an enormous set of requirements - some sensible, some onerous, some of questionable usefulness - and the cost of complying with it, and certifying that you've complied with it, can be very high.

Download the PCI-DSS 2.0 standard and be afraid.

In particular, neither of the suggested approaches are PCI-DSS compliant. Keys mustn't be stored unprotected or in the same place as the cardholder data they protect.

If you must implement this in-house, you need to isolate the components that touch card numbers from everything else, so that PCI-DSS only applies to a limited number of systems. Look at tokenisation solutions to help you keep your cardholder data exposure to a minimum. If you don't do this right you can easily drop all of your servers (or even all your corporate desktops!) into PCI scope, at which point compliance becomes difficult-to-impossible.

Authorize.net offer automated recurring billing services. For the love of sanity, use that.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • Thanks. I chose this answer because it addresses both parts of my question, not just the "How can I convince[...]" part. – M8R-53mg86 Aug 16 '12 at 22:31
  • 6
    The argument of "The fines will cost us more than outsourcing" is a very, very compelling argument. – corsiKa Jun 18 '14 at 19:22
29

"None of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner" are completely valid arguments. From a technical perspective (on the merits), they ought to end the discussion. But if you're arguing with folks who are not security experts, they may not be in a position to recognize good arguments.

So, if you find that arguing on the merits is not getting you anywhere, pull out The Sledgehammer of Compliance (does +20 damage against bureaucrats). In particular, remind them of PCI DSS. Ask them if they've priced out the cost of achieving PCI DSS compliance. Ask them for a cost-benefit analysis of how much additional revenue this feature will provide (usually, the answer is: 0) and how much the cost to the business will be (usually, the answer is: big). In most situations, that will be game over.

Or, at least it should end the discussion. If it doesn't, talk to your managers, as this is ultimately a business decision, and they should very quickly recognize the right call.

And if your managers don't get it -- well, all I can suggest is: get new managers. Maybe it's time to update your resume.

D.W.
  • 98,420
  • 30
  • 267
  • 572
7

It doesn't sound like your company has been through a PCI DSS on-site assessment before or even tried to answer all of the questions in the SAQ D. For almost every company that has, they are looking for a way to get rid of cardholder data and hoping that it isn't too costly for them to do so. If you are at a point where it is not yet costly to implement a solution, you should absolutely store your data with Authorize.net or another 3rd party.

The best argument you can make to your coworkers is to explain how big of a hassle PCI is and how much this hassle is reduced if you aren't storing the cardholder data yourself. Maintaining PCI compliance is a full-time job. If you are storing cardholder data there are so many more requirements that you must meet in order to maintain compliance (the PCI DSS SAQ D is twice as long as the SAQ C). Offloading the data is the simplest way to go. I honestly wouldn't even consider storing the data yourselves.

freb
  • 1,401
  • 8
  • 14
4

Most Bosses / Coworkers don't necessarily understand all the 'technical' issues that you might be presenting them.

Therefore you need to address them in an area that they can perfectly understand - cost / money.

One of the things that I find useful when explaining this is that if you were to get hacked and credit card information is stolen they will be liable, not only for fines but also for the cost of re-issuing a new credit card.

For example: if your company has 100,000 credit card numbers, it would cost them one million dollars for replacing those cards BEFORE they pay any fines etc (oh and by the way the CFO can go to jail if they weren't PCI compliant)

Just like they have insurance for their property

pzirkind
  • 707
  • 6
  • 12