Tenemos un sistema que almacena las tarjetas de crédito de forma segura en el archivo. Nos encantaría permitir que los usuarios se registren utilizando Facebook Connect o Twitter.
Obviamente, esto no sería seguro si confiásemos en cualquier proveedor antiguo de OAuth o OpenID, pero en el caso de Facebook y Twitter específicamente, ¿es posible implementar un proceso de registro / inicio de sesión compatible con PCI mientras se mantiene una tarjeta de crédito en el archivo?
PCI DSS v2 , Requisito 7: "Implementar medidas de control de acceso fuertes" es la sección pertinente. Esta sección detalla el control de acceso principalmente para los no consumidores que accederán a los datos del titular de la tarjeta para fines comerciales, aunque hay un par de requisitos que parecen aplicables tanto a los consumidores como a los no consumidores:
8.1 Asigne a todos los usuarios una ID única antes Permitiéndoles acceder al sistema componentes o datos del titular de la tarjeta
8.2 Además de asignar una ID única emplear al menos uno de los siguientes Métodos para autenticar a todos los usuarios: Algo que sabes, como un
contraseña o frase de contraseña Algo que tienes, como un
dispositivo token o tarjeta inteligente Algo que eres, como un
biométrico8.3 Incorporar autenticación de dos factores para acceso remoto (acceso a nivel de red) originados fuera de la red) a la red de empleados, Administradores, y terceros. (Por ejemplo, autenticación remota y servicio de marcación (RADIUS) con tokens; terminal controlador de acceso sistema de control de acceso (TACACS) con fichas; u otro Tecnologías que facilitan el factor doble. autenticación.
8.4 Hacer que todas las contraseñas sean ilegibles durante la transmisión y el almacenamiento en todos componentes del sistema utilizando fuerte criptografía
Teniendo en cuenta lo anterior, parecería que alguien podría argumentar que Facebook Connect / oAuth se consideraría un servicio de terceros que se conecta al sistema del titular de la tarjeta y, por lo tanto, se requeriría la autenticación mediante dos factores para su sistema. (Del requisito 8.3)
Aunque también podría ver el caso de que realmente no se trata de un servicio de terceros que se conecta al sistema, simplemente está facilitando la autenticación de los consumidores a su sistema.
Su QSA tendría que realizar la llamada.
Por haber realizado muchas auditorías de TI en los últimos diez años, diría que mi mayor preocupación sería tener la seguridad de que este mecanismo de autenticación de terceros funciona como debería. Un auditor que pone su cuello en la línea y las luces verdes está en una posición muy pegajosa si algo sucede en el extremo de facebook / twitter de las cosas (son objetivos populares, ya que la base de usuarios es masiva), por lo que generalmente querrían Auditar el mecanismo de autenticación ...
que de manera realista no va a suceder
Entonces, lo que ocurrirá es que se generará una excepción y la empresa tendrá que firmarla. ¿Comprenderán completamente lo que están firmando? Solo si explicas qué tan importante es esto para ellos.
Como Josh señaló, hay una redacción dentro de PCI que podría ajustarse a este caso, pero al final del día dependerá del auditor y de los dueños de negocios si desean este nivel de riesgo.
Una cosa a considerar si está considerando confiar en Twitter / Facebook para la autenticación es que ambos aún permiten que los ID de sesión se transmitan a través de una conexión no cifrada, ya que, después de la autenticación, se accede a ellos a través de http y no https.
Como tales, es poco probable que se consideren en línea con los requisitos de PCI.
La pregunta original pregunta si los esquemas de autenticación de Facebook, Twitter, etc. son compatibles con PCI.
La especificación de los Estándares de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago (CIP) cita dos cosas distintas y distintas sobre la autenticación y es el contexto de uso lo que distingue entre los requisitos:
La Sección 8 establece que se debe asignar una identificación única a cada persona con acceso a una computadora. Un nombre de usuario "principal" (de cualquier servicio) cumple con ese requisito (es único).
Esta sección continúa discutiendo la verificación de usuarios autorizados, que el componente de contraseña cumpliría. Así que esto cubre la "autenticación" básica (es esto lo que creemos que es) para la verificación del titular de la tarjeta.
Sin embargo, depende de qué acceso se concede. Para un instrumento de pago almacenado, para que el titular de la tarjeta realice una compra en su contra, esto sería suficiente (siempre que el almacenamiento de la estructura del instrumento de pago cumpla con los requisitos de PCI, etc.).
Sin embargo, para el "acceso remoto" al sistema de pago (generalmente), se requiere autenticación de segundo factor (por ejemplo, fuera de banda a través de voz / SMS, contraseñas de un solo uso). En este caso, Google sería compatible, por ejemplo, si su opción de devolución de llamada del número de teléfono se implementara como un medio de autenticación de segundo factor para el acceso remoto al sistema de pago. Si el número de teléfono no estuviera disponible o Facebook no implementa la autenticación de segundo factor para el acceso remoto al sistema de pago, entonces NO sería compatible.
Lea otras preguntas en las etiquetas authentication oauth openid pci-dss compliance