Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
We have a system that stores credit cards securely on file. We'd love to allow users to sign up using Facebook Connect or Twitter.
Obviously this wouldn't be secure if we were trusting just any old OAuth or OpenID provider, but in the case of Facebook and Twitter specifically, is it possible to implement a PCI compliant signup/login process while still keeping a credit card on file?
PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section. This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers:
8.1 Assign all users a unique ID before allowing them to access system components or cardholder data
8.2 In addition to assigning a unique ID employ at least one of the following methods to authenticate all users: Something you know, such as a
password or passphrase Something you have, such as a
token device or smart card Something you are, such as a
biometric8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dialin service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.
8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography
With the above in mind, it would seem that someone could make the case that Facebook Connect/oAuth would be considered a 3rd party service that connects to the cardholder system, and hence would be required to authenticate via two-factor to your system. (From requirement 8.3)
Though I could also see the case being made that it is not really a third party service connecting to the system--It is merely facilitating authentication of consumers to your system.
Your QSA would have to make the call on it.
From having conducted many an IT audit over the last ten years or so, I would say my biggest worry would be gaining assurance that this third party authentication mechanism works as it should. An auditor who puts their neck on the line and green-lights this is in a very sticky position if something happens at the facebook/twitter end of things (they are popular targets, as the user base is massive), so would generally want to audit the authentication mechanism...
which realistically is not going to happen
So what will happen is an exception will be raised and the business will have to sign off on it. Will they fully understand what they are signing off on? Only if you explain just how big a deal this is to them.
As Josh pointed out, there is wording within PCI that could fit this case, but at the end of the day it will be down to the auditor and business owners as to whether they want this level of risk.
One thing to consider if you're considering relying on Twitter/Facebook for authentication is that both of them still allow for session IDs to be transmited over an unencrypted connection as, after authentication, they are accessed over http and not https.
As such they're unlikely to be considered to be in-line with PCI requirements.
The original question asks if Facebook, Twitter, etc authentication schemes are PCI-compliant.
The Payment Card Industry (PCI) Data Security Standards (DSS) specification cites two separate and distinct things about authentication and it is the context of use that discriminates between the requirements:
Section 8 states that a unique ID must be assigned to each person with computer access. A username "principal" (from whatever service) meets that requirement (is unique).
This section goes on to discuss verifying authorized users - which the password component would comply with. So this covers basic "authentication" (is this who we think it is) for card-holder verification.
However, it depends on what access is granted. For a stored payment instrument, for the card-holder to make a purchase against it, this would suffice (provided the payment-instrument structure storage met the PCI requirements, etc).
However, for "remote access" to the payment system (generally) - 2nd factor authentication (out of band via voice/SMS one-time-passwords for example) is required. In this case, Google would be compliant for example if their phone number callback option was implemented as a means of 2nd-factor authentication for remote access to the payment system. If the phone number were not available or Facebook does not implement 2nd-factor authentication for remote access to the payment system then it would NOT be compliant.
