1

Let's say that company X is PCI certified and compliant as a merchant. In terms of PCI compliance, what does company X have to consider while working with third parties? E.g. for business reasons company X needs to forward hashed PAN numbers to a third-party provider. What does company X have to do in order not to violate PCI compliance?

| improve this question | | | | |
  • 1
    What do you mean by "hashed" PAN numbers? Do you mean that you literally want to send them the hash of the credit card number, because that seems strange and it's hard to see a use case for that. You may be suffering from the X-Y problem. Perhaps you can provide some more details about what you are trying to accomplish? There may be a completely different way to do it which will keep things well outside the realms of PCI compliance. – Conor Mancone Nov 14 '19 at 17:56
  • Hello. Indeed I want to send the hashed value of the whole PAN number. I want to do this for risk-related procedures related to fraudulent activities. I want to check whether two transactions have been made by the same card without actually revealing the card number to the 3rd party provider who will do this check. – elenaa Nov 15 '19 at 10:17
  • The problem with a hash is that credit card numbers have incredibly low entropy. Their means that if the person on the other end knows (or can guess) the hashing method used they may be able to simply bruteforce it to obtain the actual credit card number. There are many reputable companies that provide fraud protection services for e-commerce. I presume you are working with one of those - why don't you call their compliance office and ask about this? – Conor Mancone Nov 15 '19 at 11:17
  • Also, checking for fraud is far more complicated than checking for a credit card used more than once. All the fraud prevention services I am aware of use far more information than the PAN, and in fact I'm not even sure if they use the PAN at all. All this to say... Are you sure you're doing this right? – Conor Mancone Nov 15 '19 at 11:21
  • That's the only (PCI related) information this 3rd provider has requested. What is your opinion then? – elenaa Nov 15 '19 at 11:45
2

Although Conor is correct in his assessment of the entropy of payment cards and hashing, PCI DSS is very clear, that a hashed PAN in an environment where the PAN does not exist (e.g. the third party you have sent it to) is not considered cardholder data and does not require PCI DSS's protection. This is detailed in the PCI SSC FAQ number 1089 and for completeness here's the relevant quote:

If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS.

The URL for the FAQ is https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Are-hashed-Primary-Account-Numbers-PAN-considered-cardholder-data-that-must-be-protected-in-accordance-with-PCI-DSS

Typically the third party will provide you with a salt to use, and if they don't then I’d think carefully about their security competence....

| improve this answer | | | | |
1

In general I'm very dubious about passing along hashed PAN data to a 3rd party, unless they themselves are fully PCI compliant and certified. The issue is that credit card numbers have very low entropy and are relatively easy targets for bruteforce attacks against a hash.

For context, a naive calculation shows that a 16 digit credit card number has 1e16 bits of entropy. However, there is a check digit at the end, and the first 4 digits are typically related to the issuing bank (plus the first digit depends only on the brand, aka Visa, Master Card, etc). As a result there are at most about 1e11 bits, and probably much less than that (the last 2 or 3 times I had a card replaced, only the last 4 digits change). Even without the loss of entropy, a hashing rig like this could generate the MD5 hash of every possible 16 digit credit card number in less than a day. As a result, depending on what hashing method you use, sending a hash over may be no different than just sending the full PAN.

As discussed in comments, you're working with a fraud mitigation provider. As a result they should obviously be very well versed in PCI compliance related to these issues, and should have someone responsible for compliance that you should be able to ask about this. That's your best bet. Again, presuming that they are fully PCI compliant and certified, sending the full PAN data along to aid with fraud detection would actually be reasonable, and that is why sending a hash worries me a bit. Hashing the PAN does add a layer of protection and therefore isn't crazy, but it is also the sort of thing that someone who is not well versed in credit card security might suggest as a way of avoiding PCI compliance issues. As a result, I personally would want to talk to their compliance team and confirm that they are certified and know what they are doing.

Finally, fraud protection is a complicated process, and there is much more to proper fraud detection than simply looking at PAN data. Email addresses, phone numbers, and IP addresses are also very helpful. Finally, behavior based analytics are also a key aspect of fraud detection. As a result many fraud providers will provide a javascript file or image tag to include on every page of your site. They use this to track your users as they shop, which can lead to better fraud detection.

I'm not an expert in this area so I can't give you a firm answer, but personally I suspect that behavior analytics combined with email, IP address, etc... are the most effective way of detecting fraudulent orders. As a result if your provider isn't looking at behavioral analytics, I'd chalk that up as another reason to be dubious.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.