cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
iluom
Contributor II

PCI-DSS

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

 

 

 

Mouli, CISSP
10 Replies
jimscard
Newcomer III

What you describe is the best practice -- especially since PANs may never be stored in the clear -- they must always be rendered unreadable, and rendering them unreadable via a one-way cryptographic hash is one of the best ways for a system like this. Especially considering that since running a given PAN through the hash algorithm and then searching for entries in the register that match would satisfy most use cases, e.g., "provide a list of all transactions that the card with the PAN 4444 4444 4444 4444 was used in."

 

Keep in mind, though, that legal obligations, such as national or local laws do supercede PCI DSS requirements, even if they increase risk. It may be possible, however, to comply with both, e.g., by strongly encrypting the CHD in the register, decrypting it only as required to respond to legitimate requests as required by your law (check with your legal advisors).

Jim Scardelis, CISA, CISSP, PA-QSA(P2PE), PCI 3DS Assessor, PCI SSA, PCI SSLCA, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, MCSE
Any views or opinions contained in this communication are solely those of the author.