PCI-DSS

[iluom]

Hello pals,

I'm using an e-commerce application which collects Credit card data and save in a database.

So far it's fully compliant and following PCI-DSS standards. 

But this credit card data is being sent from an internal app server to a third party payment processing company by calling 3rd Party REST API. There is no human interface.It happens internally.

currently the data is being passed in a plain text format, card number as is,  but the communications between my app server to 3rd party API is over https.

I'm thinking if  obfuscation/anonymization/tokenization/masking can be used. Not sure if really required as per PCI-DSS . Does it fall under PCI-DSS compliance ? What is best way to handover Credit card data to 3rd party in this scenario.

i'll be grateful for your suggestion

Thanks

[jimscard]

Hi Mouli,

If I understand this correctly, you have a payment system that handles payment cardholder data (CHD) including the primary account number (PAN) and some other elements of card account data. Your app server, on your internal network, connects to your processor's Internet-facing REST API over HTTPS with strong cryptography (TLS 1.2 or higher, with strong ciphers). 

Inslde the HTTPS tunnel, the CHD is plain text.

Your question is whether PCI DSS requires you to provide additional protection to the CHD via one of the methods you listed?

PCI DSS Requirement 4 requires that CHD be protected while in-transit via strong encryption, and that only trusted certificates be accepted. It is perfectly acceptable for you to send plaintext CHD over a strongly-encrypted tunnel, as long as you are also validating the TLS certificate being presented by the processor's API to confirm that you are actually connecting to the trusted site that you are expecting to.

Obfuscation is not a security control, and would not apply in any situation.

Anonymization, which could be accomplished via rendering the CHD unreadable via hashing with a strong cryptographic hashing algorithm (such as SHA-256) with a unique salt, would certainly protect the CHD, but would also render it unreadable by the processor.

Tokenization is not typically applicable in this context. Usually tokenization comes into play when you are looking for a way to simplify your PCI DSS compliance tasks by storing tokens instead of actually storing CHD. This works when the tokenization has been done by a third-party, for example, many processors will return a token in an authorization response that can be stored instead of the PAN. Then, when the merchant needs to process a recurring charge, they can submit the token instead of a PAN (the stored token is not considered to be CHD because the merchant does not have the means of de-tokenizing it.

Masking does not apply in this context. In PCI teminology, masking is a means of rendering CHD unreadable *when displayed or printed*. The term for removing digits other than displayed/printed is "truncation". Truncation, like masking, would not help in this case, as it would render the CHD unreadble by the processor.

I also wanted to make sure that you were aware that any system that stores CHD, such as a database, must not be directly connected to the Internet.

Jim

[iluom]

Thank you Jim

[iluom]

Hi Jim,

PCI DSS requirement 3.3 states “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).”

I've been reading through PCI compliance rules to see if it is ever PCI compliant to display the full credit card number on a webpage to a user.

because one of my third party payment processing company is displaying full credit card number without any masking. Is it really acceptable? I mean if the number is being displayed to the card owner, will the requirement 3.3 still valid & applicable in that context?

It was observed that application exposed full customer card number in clear text without any protection for shoulder surfing.

It was also observed that customer card details are exposed in clear text in hidden fields. is this a violation?

what is your suggestion in this scenario.

Thanks

[jimscard]

Hi Mouli,

Your question is a good one, as the answer is not as clear as it might seem at first look.

You are correct that PCI DSS 3.3 covers the requirement that PAN be masked when it is displayed. However, there are a few nuances to the requirement that are important to understand. First, let me start by quoting the full requirement:
"3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN."

Ok, so there already is an exception stated in the text of the requirement - for the case when " personnel with a legitimate business need" have to see full PAN. So, for example, in the case of a third party processor, displaying full PAN on a web interface might be OK if it's only for a person with a legitimate business need, for example, someone who needs to look up the details of a transaction,including full PAN, in order to process a refund.

The second nuance focuses in on the meaning of "displays", which can be subtle. Consider this - you have a payment page, into which a cardholder or a merchant employee enters CHD for a transaction. Is the visible result of their typing in a text field an instance of "displayed" CHD requiring masking?
In most cases it's not. If it's just a field into which the user is typing something, and it's visible while being typed, and after, without the page refreshing, then it's not an instance of "displayed" CHD, and masking isnt needed.

On the other hand, when the page refreshes, and data is written back to the client, for example, on a confirmation or receipt page, then that has to be masked.

Another similar case that we would run into especially when doing PA-DSS validations is the distinction between merchant facing and customer facing displays. In the US, for example, a merchant facing display or printout can have any PCI DSS compliant masking, eg, first 6,last 4 digits. However, Federal Law also limits how much of a financial account number may be shown on a consumer facing display or printout like a receipt, and that limit is the last 5 digits. So, the intersection of PCI DSS and Federal Law means that only the last 4 digits can be on a consumer facing display or printout.

Also, please note that first 6 last 4 is valid for any PAN, regardless of brand or PAN length. There is an FAQ on the SSC site covering what is allowed if one of the new longer format PANs are used.

[iluom]

Hi Jim,

Very nice detail on the nuance of display, masking and how these definitions should be interpreted in the context of browser sessions.

Regarding other part of the question- Storing full card number in the hidden field in plain text

it's surprising to know a payment processing company for (3DS1.0 implementation) is storing full CC number in a hidden field in plain text.  I think it's a  implementation mistake and vulnerability and associated high risk of noncompliance.

My thoughts:

According to PCI-DSS anything that stores and processes credit card information falls under PCI-DSS regulations and if we do it this way (hidden field) it may lead to compliance risks, moreover it creates legal and financial liability to the company using it. The classic example of this security flaw is a retailing application that stores the prices of products within hidden form fields. In the early days of web applications, this vulnerability was extremely widespread, and by no means has it been eliminated today.

and it is easy for a malicious user to see and modify the contents of a hidden field. so i prefer we should not store any information in a hidden field that is sensitive. Basically, by hidden fields, we understand just input text fields that are not visible on the page for the user. Even if the corresponding HTML code is available in the page source code, the user is not aware about the presence of the hidden field. So, the user cannot type anything in a hidden field. So, hidden fields are commonly used for submitting data in a silent manner, and can be the perfect choice for dealing with temporary and insensitive data, or information provided by the user that should be used again and again.

The PCI Security Standards Council (SSC) defines ‘cardholder data’ as the full Primary Account Number (PAN) or the full PAN along with any of the following elements:

• Cardholder name
• Expiration date
• Service code

According to PCI-DSS requirement 3.4

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography, (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures.

It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

[MickGrill]

@jimscard not trying to highjack this thread as it is already answered but noticed your response regarding displaying PAN in a web portal for a 3rd party. Am I correct in my understanding of your response that it is allowed under PCI to display full PAN in a web portal to a 3rd party as long as there is a legitimate business need?

Regards,

Mickel

[jimscard]

Hi Mickel,

It can be, for specific users. Otherwise, for instance, a processor would not be able to display the full PAN in a portal to enable the merchant to research a transaction etc.

The specific PCI DSS v3.2.1 requirement is req. 3.3, which requires that PAN be masked when displayed "such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN."

There are a couple of important clarification points, though:

1. You used the term "Third Party" - the standard uses the term "personnel". That means that the user with a legitimate business need can't just be anybody - it would have to be someone who works at one of the involved parties. So, someone at either the merchant or their service provider.
2. The user must have been assigned to a role - and that role must be one that is on the documented list of roles that need access to more than first 6/last 4 digits. The legitimate business need for each of those roles to have access must also be documented.
3. All roles not specifically authorized to see the full PAN must only see masked PANs.

Sometimes that can be a bit blurry, so let me give an example. Take a multi-merchant e-commerce site like EBay or Amazon. The entity that owns and operates the site is a service provider that is processing transactions on behalf of their merchant clients, and also supports consumer accounts that cardholders use to buy stuff from the merchants' stores.
Under 3.3, it would be compliant, for example, for the e-commerce site owner to have a page, accessible only to specific merchant employee accounts that have been assigned to a particular role, that displays full PAN for some legitimate business purpose that they're authorized for.
It wouldn't be compliant, however, for them to have such a page that anyone could access, or that a cardholder themselves could access. (In the US, by the way, there's other laws prohibiting display of full account numbers on consumer facing displays or printouts).
Note also that the merchant accounts that I just described are examples of "non-consumer users" accounts that are mentioned in various sub-requirements and testing procedures under Req. 8, including 8.1.* and 8.2.*.
Also, with a web-based application, the masking would need to be done on the server side.

[MickGrill]

Jim,

I appreciated the quick response to my question. I've submitted the same question to our PCI assessor who has provided a similar response as yourself.  My interpretation of requirement 3.3 lead me to believe that it was compliant, however, I have colleagues that didn't agree with me and so I felt it best to reach out to our assessor and the internet to see what others interpretations were. I have been finding like you've said some things are a bit blurry and open to the interpretation of the individual reading the PCI document.  

Regards,

Mickel

[eugeneromanenko]

Hi Jim,

thank you for your clear explanations here.
My company as 3-rd party payment provider use hash method for hiding PAN internally and we are preparing to an audit by our National Bank, where according to local AML law we have to store a register with transactions data including unique account numbers. 

Do you have an idea if it would be correct from our side to insist that due to obligations to be compliant with PCI DSS we use hash numbers as unique card identifiers and we have not to use PANs of clients in the register for the National Bank (as such datasets can be sent to the National bank even on the USB flash drives), and only in case of an appropriate request from the National Bank as our regulator (or Police only?) we could decrypt hash and provide a PAN to the bank. And as for AML-monitoring obligations we use hash card number and card mask to meet its purpose:
- by the hash we check the intersection of a unique card with other transactions,
- by the mask, if necessary, we confirm the legitimacy of the transaction and the cardholder's data in his/her issuing bank.