PR6 Encryption and PCI/PA-DSS

[perholmes]

Hi Rick,

I noticed that you're now encrypting merchdb.dat, which contains the database passwords. We have about 20 custom modules that all fetch the database password from this file, so our store would break if we upgraded. Obviously, we've done this in a wrong way, but what is the right way?

1.) Can we decrypt the password ourselves from merchdb.dat? How is it encrypted in the first place, and with which key?
2.) Can we read the password from a global variable?

Secondly, I've contacted your support a few times to no avail regarding getting unencrypted payment data passed to a fulfillment module. Our fulfillment process *depends* on having access to order data, because it is mined heavily for real-time fraud scoring and AVS data, and it is the singular reason we've only had 2 chargebacks ever in 5 years and several million dollars in transactions. So this system clearly works.

But when Store Encryption is used, the payment data sent to the fulfillment module is also encrypted. We would break PCI if we hardcoded the decryption key, and we're also currently breaking PCI by running our store unencrypted, but flushing the payment data from the Miva database immediately after we've used it -- so it's being physically written to disk and deleted 0.01 seconds later.

Since the fulfillment module is a secure environment, I can't figure out why you're sending un-decryptable payment data to the fulfillment module -- and I would love to simply have misunderstood something simple.

But nevertheless, we need to come up with a solution that is PCI compliant. Assuming that you're intent on sending encrypted data to the fulfillment module, my next question is this:

Would it be possible for me to change the database schema for the Miva database to make pay_secdat a VARCHAR(1)? That way, the unencrypted payment data would be sent to MySQL, but it would be truncated beyond recognition. That would bring us closer to some sort of PCI compliance, but a malicious employee could reverse this simply by changing the field back to a Mediumtext, so I don't really know if it would pass a PCI code review -- but at least it would prevent the encrypted payment data from being written to disc, and merely held in memory for a short time while sent to MySQL. And even so, MySQL might actually cache the query to disc, which would write the unencrypted payment data in a cache file. So this might not be a very good solution, except to get some temporary security.

But what are you doing sending encrypted payment data to the fulfillment module in the first place? This is a safe environment, and our module is being called by *your* engine. If your environment is safe, then our module executes inside your safe environment, so it's bizarre that you would send encrypted payment data to the module, data that can only be unlocked by breaking PCI.

Our fulfillment module easily passes an independent PCI code review, but the issue that keeps coming up is that the only way to get OUR data in the first place is to configure the Miva store to not be encrypted, which thus creates an unescapable PCI problem no matter what we do.

Again, I would LOVE to just be an idiot and have misunderstood this and it's like "oh, you just have to get the payment data from this field instead". But it's really a problem. This single thing is stopping us from being PCI compliant. It's obviously not an option to stop fraud scoring, or manually babysit the data through every single stage of some new manual offline fraud scoring system we'd then have to program. That would be a giant, and extremely lame step down, and completely unnecessary, since everything is happening inside an environment that is supposedly secure. It's not right for the Miva engine to mistrust a friggin' fulfillment module so much that it treats it as enemy code.

I hope you'll tell me that I've misunderstood this whole thing.

Best,

Per

[kayakbabe]

Re: PR6 Release Update and Notes - Part 1

well, you could always have a second config file.
I find that an impracticle method as it has burned me in the past (forgot to update them all, silly me).
But if it's the only way to get around it.. you might have to.
Just make sure you keep it out of your web assessible folders.

You could also use your own sha1 encryption to encrypt your 2nd config file.
In php there is a fuction to handle that .

You should specify your own salt phrase, (which also has to be stored somewhere on the server.)

That get's me thinking, salt phrases are stored so they can be compared agaist on subsequent uses. If we can find where miva merchant stores it's salt, then we can still use the miva config file as our resource for db connection. We need to use the same salt phrase that miva merchant is using and use the sha encryption/decryptoin functions in php. Since they live on the same server and the ssl and all that is the same it will probably work fine.

Can anyone pass some info on where to find the salt?

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Hi,

Yes, that might be the only solution. I do need the credentials, not only to access the Miva database, which I do in about 10 modules, but because we run a database next to the Miva database with all our own data, and we're purposefully made it so it has the same login credentials.

I'm not really sure why miva are encrypting this data, because if you have the type of root access needed to access the file in the first place, you also have a root log/pass you can pop right into phpMyAdmin and get the data anyway. Assuming that the protected data is encrypted using a proper public/private key scheme, I can't see why it's necessary to encrypt the off-root database credentials.

But this can be solved. The main issue for us is that Miva sends encrypted payment data to fulfillment modules. We've so far been running our store unencrypted in order to access our data and then wiping the payment data from the Miva store immediately after, but this is not PCI compliant.

We are heavily dependant on our fraud-scoring system, and I find it mind-boggling that Miva decides that our fulfillment module has no right to even get the Authorize.net AVS result. Given that we've only had to chargeback ever, and that's for 5 years and millions of dollars in transactions, our fraud scoring system obviously works. Unless Miva allows to access our own data, data we have a right to, we have NO MEANS to become PCI compliant. It's as simple as that. In order to become PCI compliant, we would have to dismantle our entire fraud scoring system and become blind as bats. No professional store should accept having the fraud result from their credit card processor censured by the shopping cart. This is bizarre.

I have these two questions posted on the help desk. Crossing my fingers for a non "sorry, you can't have your data, good luck with your store!" answer.

:-)
Per

[Rick Wilson]

Re: PR6 Release Update and Notes - Part 1

I'm not really sure why miva are encrypting this data

It's required for us to become PA-DSS Certified.

I haven't ignored all the questions from your previous post, I'm out of town at Hosting Con and I need Jon Burchmore's assistance to fully answer your questions. I would guess I'll post detailed answers to this thread on Friday.

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Hi Rick,

I'm not kidding you that I'm literally starting to get cold sweat, because what you're suggesting is that we have to kill any real-time usage of AVS results and BIN numbers (first 6 digits of credit card number), we have to kill our link to MaxMind for fraud scoring, and we have to kill any automation of fraud analysis to allow low-scoring orders through to order fulfillment. In other words, we have to park ALL orders and do manu fraud scoring on ALL orders, stalling EVERY SINGLE order until a person has been able to log into a new offline fraud scoring system we have yet to program and manually entered a decryption key. Sir, this is awful, awful, awful.

We are in big trouble. My God. Wow. I'm absolutely stunned and bewildered, and I have no idea what we're going to do.

But you say that this is required for you to become PCI-DSS compliant? How so? I don't recall anywhere in the PCI spec where it says that one module in store is not allowed to send payment data to another module. This data is not stored. We use the BIN part of the order number (first 6 digits) to submit to Maxmind along with a plethora of other data, all a PCI compliant process in itself as PCI specifically ALLOWS you to handle the BIN number and transmit it to third parties. We combine this with Authorize.net's AVS result and much other data to come up with a fraud score that determines whether the order goes straight to fulfillment or is held for human review. Because of this, our chargeback rate is 0.0001%, better than any store our processor has ever head of.

PCI doesn't just require you to follow instructions blindly, PCI asks you to have a brain and use common sense. It is not common sense to not allow a fulfillment module access to any of the key data that allows it to make a fraud decision.

Having read the PCI spec, I have absolutely no idea which text you're interpreting as to require you to keep payment data away from the store itself. On the contrary, you're reading it wrong. Just because the payment data exists in memory when a fulfillment module does not give you any liability. The responsibility is SPECIFICALLY ON THE MODULE. WE are required to do a code review, because it's OUR code that touches the payment data. I have a third party ready to do that review, an Application Security Analyst from Microsoft who works with their Azure platform.

You're reading PCI wrong. It specifically says that WE are responsible. If you're worried about even having the data exist in memory while the module is called, all you have to make is a store preference called "Send unencrypted payment data to fulfillment modules?", which people have to digitally sign. At that same time, you ask people to agree that by receive unencrypted payment data in a fulfillment module, the store owner is responsible for PCI compliance of any code that "touches" the payment data.

I also don't completely buy the argument of this being a PCI concern. If you were concerned about PCI to that extent, you would start logging any access to payment data through the admin panel. PCI specifically requires you to do this, and actually we also intend to store payment data in a more PCI compliant way than you do, with proper access controls and logging, which you have none of currently. If a Miva store was broken into right now, without an access log, the store owner, or Miva, would be fined.

So on multiple levels, you're reading the PCI spec wrong. There's NOTHING in the PCI spec that requires you to send encrypted data to a fulfillment module. The handling of that data specifically becomes the store owner's or the module developer's responsibility. I'll be happy to fetch a quote from the PCI spec if it would help.

But assuming that you're intent on your own interpretation of PCI, my next question is if it's possible to commission you to program a version of the module that calls the fulfillment module. I way pay anything that you want, please PM a price. The alternative -- giving up fraud scoring -- is devastating. So a few thousand dollars won't matter in that regard. So please name a price. I'll be happy to sign an agreement that I assume full responsibility for PCI compliance of any alternate version of this calling module, as well as our own code (PCI considers us the primary responsible party anyway, you've misunderstood your own point of responsibility).

Best,

Per

[Rick Wilson]

Re: PR6 Release Update and Notes - Part 1

Per,

I didn't mention PCI-DSS, I mentioned PA-DSS and our encrypting that database was not something we interpreted but we were instructed to do by our auditor.

As for your situation, I'm sure there's a solution, but as I said in my previous post I'm at a conference all week. Can you sit tight until Friday so I can get you a detailed answer?

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Yes, I definitely can. Our PCI review is about two months from now, and we have almost everything down.

One thing you might consider is that you're censuring too much of the data. About a billion receipts are printed every day all over the world that include the last 4 digits of the card used and the authorization code, and by sending encrypted data to the fulfillment module, you're encrypting it so severely that it's not possible to produce a normal receipt. This is clearly overzealous.

In addition, you're suppressing the AVS result, which the Authorize.net specifically intend to aid in screening for fraudulent orders. Finally, you're suppressing the BIN number, which prevents us from determining which bank the customer belongs to, which is part of our fraud result (if the bank country mismatches several other indicators).

To be PCI compliant, you could in fact pass on the ENTIRE pay_secdat unencrypted to the fulfillment module and mere prune the middle digits, i.e. 123456XXXXXX1234. Both the BIN and the last 4 digits are allowed to be handled in an insecure environment (if you really do consider a fulfillment module an insecure environment), and the AVS result is encouraged to be used. You would therefore take a far bigger step towards credit card security by giving the fulfillment module as much as possible to work with, and merely suppress information that is not required for any other purpose than storing the credit card number. So if you simply prune the middle 6 digits, and send it unencrypted, you're off the hook.

Sorry for getting upset, but it would be devastating for us to give up fraud scoring. Right now we're doing it in a way that won't pass PCI compliance, but choosing between PCI and reduced fraud, we'll have to choose reduced fraud. However, this is not sustainable, because it depends on a hack that allows data to be stored unencrypted inside Miva. I assume that this functionality will disappear from Miva Merchant soon, as it's hardly a compliant option to give merchants.

Thanks, Rick, I'll take it as encouragement that you believe something can be worked out.

Best,

Per

[Rick Wilson]

Re: PR6 Release Update and Notes - Part 1

One thing you might consider is that you're censuring too much of the data. About a billion receipts are printed every day all over the world that include the last 4 digits of the card used and the authorization code, and by sending encrypted data to the fulfillment module, you're encrypting it so severely that it's not possible to produce a normal receipt. This is clearly overzealous.

Per, this is not something WE decided to do. It's MANDATORY for us to become PA-DSS Compliant (which is different than PCI-DSS).

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Hi,

It's just that by those standards, NewEgg and Amazon.com would also fail PA-DSS, because they use real-time data during checkout, as do pretty much every retailer. I understand that you're a shopping caret provider, but there has to be a way for you to be compliant, and at the same time not force every Miva store-owner to run a lame store from the previous century. I can't see how it's possible to work with any fulfillment company in real-time without access to data that would enable you to fraud score orders -- then every order would be submitted to order fulfillment regardless of how outrageous a fraud score it would have had. I'm going to read PA-DSS, because I can't possibly believe this. Without access to this data, we can't run an even moderately professional fulfillment process.

Are you willing to work with us on this, so *we* at least can get a fulfillment process without censured data? I am willing to pay any 5 digit dollar amount for the assistance needed from your end and sign any contracts that absolve you of responsibility.

This is such a devastating and severe issue for us that the only alternative is to completely drop your Authorize.net module, and program a new one from scratch, just so we can access OUR data.

We cannot give up fraud scoring, I hope you understand that. And since the BIN number is a central part of the fraud scoring, because it is matches the bank to the shipping/billing, which is matched to the AVS and the IP location, and give a very sophisticated fraud picture. We have NEVER had a false negative on this process in 5 years, and our system depends on it, as does our agreement with our credit card processor -- they allowed us to electronically deliver some of our products exactly because of this system.

I will look into what it will take us to program an Authorize.net module from scratch. But I really detest this situation, having to program a new payment module from scratch just so I can access the God-darn fraud score contained in the result. PCI and PA-DSS are about preventing fraud, not putting up barriers to make fraud easier. And I still believe you're reading it wrong, or your auditor is reading it wrong. You are forcing Miva stores to be less professional than countless retailers, and countless credit card terminals. And PA-DSS and PCI do not force merchants to not print the last 4 digits and the authorisation code, Miva is the only solution in the entire world that works like this. Therefore, you must be reading it wrong.

So I guess I answered my own question. We have to program our own Authorize.net module. Unless you're willing to work with us and any other merchant who requires access to data that if fully allowed within PCI even in an unencrypted environment.

Best,

Per

[kayakbabe]

Re: PR6 Release Update and Notes - Part 1

I"m very interested in this conversation too. We are in the midst of moving parts of our business to Sage Mas 500. We're going to be integrating it with our miva merchant store sytems to some extent. This has an impact on us as well. We may well have to do things 'differently' than planned. Though we are going to be pci compliant. It seems that some work arounds to make things work that I can envision off my cuff could actualy create loopholes for secuity issues instead of preventing them. I look forward to this conversation beginning on Friday too.

[Rick Wilson]

Re: PR6 Release Update and Notes - Part 1

Per,

I believe we can help you and there's a way to do what you want within our parameters. I'm out of town until Friday, let's hold off on any more discussion until then.

The only thing I've answered thus far is why we've encrypted it, and the answer is simple we had to in order to be PA-DSS compliant.

That doesn't mean there's not compliant answers to your issues, it simply means we had to do it and we'll help you solve your problem from here.

Give me until Friday and I'll get you detailed answers to all of your questions.

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Hi,

The only possibility that it could be a security risk to send payment data to a fulfillment module is if that module crashes in a way that makes a complete variable-dump on the screen. But any fulfillment module that intentionally touches payment data is automatically the responsibility of the developer, not of Miva. It's very very simply written in PCI that the moment we touch payment data, it becomes our responsibility, and then we have to submit to a code review. We've already had a 1/2 code review, and the full code review will happen once this issue is resolved.

The question, and the place where Miva may have an argument, is whether simply having the payment data exist as a variable in memory that could be access accidentally or intentionally, constitutes "touching" the payment data. In the most conservative interpretation, I can understand how that may be considered "touching", especially if this data is sent to a fulfillment module that may not be aware that payment data is sent to it, and therefore not prepared for it, and may not crash gracefully.

That's why I suggest two options to Miva:

1.) Make it an option. If you have merhants enable a checkbox where they sign an electronic agreement that all fulfillment modules in the store must be under the control of the store owner, and that the store owner assumes full PCI and PA-DSS responsibility for those modules, including submitting them to code review (he has to anyway) -- then Miva is off the hook without leaving merchants to drown at sea.

2.) Miva could just blank out the middle of the credit card number and send the rest of the data as is. Then it is no longer consider secure payment data. The BIN is allowed to be handled, and the last 4 digits are even allowed to be printed in an email, which is fully public from a security perspective.

In any case, sending undecryptable payment data and fraud results to a fulfillment module is a kick in the teeth.

If any other developer is reading along here, does anyone have some code that can contact Authorize.net? Otherwise, I'll have to look into writing an Authorize.net module from scratch. Oh, how I hate the idea of managing a payment module -- this opens up a massive potential point of failure. No doubt, there will one day be an API change at Authorize.net, and since we had to have our own module, we'll be the last merchant in the world to get back online. So this is almost guaranteed to cost a ton of money several years down the line.

Best,

Per

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Hi Rick,

Sorry for the cross-posting. I'll tame myself and hold until Friday.

Thanks,

Per

[perholmes]

Re: PR6 Release Update and Notes - Part 1

In the background, could you also ponder the question about whether the database credentials exist as a global variable even though merchdb.dat will be encrypted in the future? Or can we know how to decrypt it? I'd rather not maintain database credentials in multiple locations, that has failure written all over it. But we do need to access the database, as well as our own database which uses the same credentials.

Thanks,

Per

[perholmes]

Re: PR6 Release Update and Notes - Part 1

Final note, in case you missed it previously: I don't know if you're planning it, but there actually has to be complete logging of access to payment data to be PCI compliant. PCI spec requires that each person has their own login, and that decryption of payment information is recorded in a log.

Best,

Per