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?

4 Answers 4


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

8.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.

  • Maybe I'm just uninformed, but where is the second factor here? Does a Facebook connect user have to use more than a password to authenticate? I think you could posit a third party Identity Provider that does require two-factor authn, but do these two qualify?
    – nealmcb
    Jan 25, 2011 at 3:27
  • @nealmcb I'm sorry, but I am not sure I understand your question. Could you please clarify? Jan 25, 2011 at 3:50
  • Which two factors (as enumerated in 8.2) are used by Facebook to authenticate a user, as required by 8.3 for remote access. And by "these two" I meant do either Facebook or Twitter qualify.
    – nealmcb
    Jan 25, 2011 at 5:14
  • 1
    @nealmcb, I think @Josh was saying "8.3 would require 2factor authN, which they obviously don't have, and therefore they are clearly not compliant."
    – AviD
    Jan 25, 2011 at 6:49
  • 1
    That said, even if it is not considered a 3rd party, PCI would still require you to audit (and control etc) the authentication mechanism.
    – AviD
    Jan 25, 2011 at 6:49

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.

  • 1
    Can you clarify whether this actually affects the use of the OAuth option? When using Facebook Connect or Twitter's OAuth service does the user have to cleanly and securely authenticate? After that it would be up to the rest of OAuth, which I'd hope is clean, and then the session id from the relying party on the credit-card-using site, which should of course be TLS.
    – nealmcb
    Jan 25, 2011 at 3:24

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .