PCI DSS v2，要求 7：“实施强访问控制措施”是相关部分。本节主要针对将出于商业目的访问持卡人数据的非消费者详细介绍访问控制，尽管有一些要求似乎适用于消费者和非消费者：

8.1 在允许所有用户访问系统组件或持卡人数据之前，为所有用户分配一个唯一 ID

8.2 除了分配唯一 ID 之外，至少使用以下方法之一对所有用户进行身份验证： 您知道的东西，例如
密码或密码短语 您拥有的东西，例如
令牌设备或智能卡 您的身份，例如
生物识别

8.3 为员工、管理员和第三方对网络的远程访问（源自网络外部的网络级访问）结合双重身份验证。（例如，带有令牌的远程身份验证和拨入服务 (RADIUS)；带有令牌的终端访问控制器访问控制系统 (TACACS)；或其他促进双因素身份验证的技术。

8.4 使用强密码术在所有系统组件上传输和存储期间使所有密码不可读

考虑到上述情况，似乎有人可以将 Facebook Connect/oAuth 视为连接到持卡人系统的第 3 方服务，因此需要通过双因素对您的系统进行身份验证。（根据要求 8.3）

虽然我也可以看到它不是真正的第三方服务连接到系统的情况 - 它只是促进消费者对您的系统进行身份验证。

您的 QSA 将不得不对此进行调用。

在过去十年左右进行了多次 IT 审计之后，我想说我最大的担心是确保这种第三方身份验证机制能够正常工作。如果在 facebook/twitter 结束时发生某些事情（它们是受欢迎的目标，因为用户群很大），那么如果审计员将他们的脖子放在线上并开绿灯，这将处于一个非常棘手的位置，所以通常会想要审核认证机制...

这实际上不会发生

所以将会发生的事情是会引发一个异常，并且企业将不得不签署它。他们会完全理解他们签署的内容吗？只有当你解释这对他们来说有多大意义时。

正如 Josh 指出的那样，PCI 内部有适合这种情况的措辞，但归根结底，他们是否想要这种风险水平将取决于审计师和企业主。

如果您正在考虑依赖 Twitter/Facebook 进行身份验证，需要考虑的一件事是，它们仍然允许通过未加密的连接传输会话 ID，因为在身份验证之后，它们是通过 http 而不是 https 访问的。

因此，它们不太可能被视为符合 PCI 要求。

最初的问题是询问 Facebook、Twitter 等身份验证方案是否符合 PCI 标准。

支付卡行业 (PCI) 数据安全标准 (DSS) 规范引用了关于身份验证的两个独立且不同的内容，并且区分要求的是使用上下文：

第 8 节规定，必须为每个具有计算机访问权限的人分配一个唯一 ID。用户名“主要”（来自任何服务）满足该要求（是唯一的）。

本节继续讨论验证授权用户 - 密码组件将遵守。因此，这涵盖了持卡人验证的基本“身份验证”（我们认为是这样）。

但是，这取决于授予的访问权限。对于存储的支付工具，对于持卡人对其进行购买，这就足够了（假设支付工具结构存储满足 PCI 要求等）。

但是，对于支付系统的“远程访问”（通常） - 需要第二因素身份验证（例如，通过语音/SMS 一次性密码带外）。在这种情况下，例如，如果他们的电话号码回调选项被实施为远程访问支付系统的第二因素身份验证的手段，那么谷歌将是合规的。如果电话号码不可用或 Facebook 没有为远程访问支付系统实施第二因素身份验证，那么它将不符合要求。