Viewing PCI data via 3rd party sites securely

Question

I'm working on a project that requires PCI protected data (card PIN numbers) to be made visible to customers, via a Third Party (a non PCI compliant) company site.

The hierarchy is as follows:

• Us > PCI Complaint > Platform Provider
• Third-party > Not PCI Complaint > Our Customer
• Customer > Card User > Third Party Customer (but we are responsible for financial data)

We can show the PIN via a web page (if it is served under SSL) but we cannot allow the PIN to be passed to the Third Party in any way in case it is stored. So REST calls are out of the question, as are iframes.

The ideal process would be:

1. Customer visits the Third Party site and requests to view their card PIN.
2. The PIN is displayed (served from our site) on a page served under SSL.

The process required to do this is difficult to figure out because:

• We need the PIN request [to appear] to be made from the Third Party site as the customer is 'theirs', we provide the platform for the cards.

• We need it to be served under SSL to meet PCI compliance.

• We cannot serve this with a REST call to the Third Party.

• We cannot have the Third Party retrieve this PIN in case it is stored or an app is written to scan and retrieve all their customers PIN's.

• We need all this to be managed via Web Browser(s) and transparently, so the customer doesn't have to enter a password or provide an encryption key.

We can show the PIN on one of our own unbranded pages but I cannot see how we can pass any required sensitive data (via the Third Party site) to instantiate this request - without providing/leaving sensitive data on the Third Parties site.

This doesn't sound possible to me - without the customer providing some sort of secret key to retrieve the PIN "directly" via the Third Party Site. But I wanted to ask, in case somebody has any ideas or has experienced similar issues?

Thank you in advance!

Answer 1

First of all, you need to talk to a QSA on something like this.

That said, I believe the PCI Card Production Logical Security Requirements document most closely applies to your issue. And the sticker is that the cardholder does need to provide "some sort of secret key." Specifically, section 10 PIN Distribution via Electronic Methods says you need to validate that the request is coming from the cardholder:

e) Communication of the PIN to the cardholder must only take place after verification of the identification value and associated authentication value.

f) The identification and authentication values must not disclose the account number.

g) The authentication mechanism or value must be different than the identification value and must not be a value easily associated with the cardholder.

h) The authentication value must be communicated to the cardholder in such a way that access by anyone other than the cardholder is detected.

h) also implies that the cardholder can't pass their authentication value through the third party, but you knew that.

You're correct that REST or web services would not be appropriate, but an iframe is probably acceptable, because an iframe means that the communication regarding the PIN would be directly between the cardholder's browser and your server, bypassing the third party. The third party simply provides the link that allows the cardholder to go directly to you. iframe is probably the appropriate technology to meet your requirement of having it appear to come through the third party and the PCI requirement of requiring the transaction be directly between you from the cardholder.

Alternately, you could simply do a branded page. You create a web page with the look and feel of your third parties' web site, and they link to your page. Cardholders go to your site, your URL, but it looks enough like the third party to seem the same.

So, to sum up - the third party passes the cardholder to you, via iframe or direct link. The cardholder submits authentication data to you and gets the PIN back, and ends up either continuing (iframe) or being redirected back to (direct link) the third party's site.

You may not be able achieve one of your goals: to do this "transparently, so the customer doesn't have to enter a password or provide an encryption key." That's not compatible with PCI requirements. (That said, if your QSA approved, and the third party was able to sufficiently authenticate the cardholder through their normal process, and pass cryptographically strong proof of that along as a cookie or request parameter, then maybe you could make it transparent. But that's where you really, really, really need a QSA's advice, because maybe that violates 'h' above)