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
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.
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.
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.
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:
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:
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.
@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?
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.
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.