5 conceptos clave de la nueva guía de autenticación del PCI SSC

A finales de agosto de 2025, el PCI SSC publicó dos nuevas guías (suplementos informativos) relacionadas con autenticación y criptografía. Aunque estos documentos no cambian la aplicabilidad y/o obligatoriedad de cumplimiento de los controles de PCI SSC relacionados, sí que complementan y detallan una serie de aspectos técnicos y administrativos que deben ser tenidos en cuenta tanto por los asesores QSA como por las entidades que deben cumplir estos requerimientos.

En este primer artículo se analizarán 5 conceptos clave de la guía de autenticación (Information supplement – Authentication Guidance) versión 2.0 Revisión 1, publicada en agosto de 2025. Este documento remplaza la guía publicada en febrero de 2017, incluyendo cambios muy importantes en los procesos de implementación de la autenticación multifactor (Multifactor Authentication – MFA) y contiene recomendaciones alineadas con el estándar PCI DSS v4.x. Igualmente, amplía su ámbito de alcance a todo el concepto de autenticación y no solo a la autenticación multifactor, como sucedía en la primera versión de esta guía, ofreciendo recomendaciones muy interesantes aplicables a este proceso.

Es igualmente importante anotar que este documento está acompañado de una infografía muy interesante que contiene un resumen gráfico de los conceptos descritos en la guía, incluyendo 16 mejores prácticas en el uso de sistemas de autenticación.

Mejores prácticas en el uso de sistemas de autenticación

Introducción y conceptos básicos

Antes de empezar con el análisis de los 5 conceptos más importantes de la nueva guía de autenticación, conviene realizar una introducción a los conceptos básicos de este proceso, para lo cual se presenta a continuación un extracto del artículo «Análisis de PCI DSS v4.0 – Parte V: Requerimientos 7, 8 y 9«, en donde se analizaban los cambios a estos requerimientos en la versión 4.0 de PCI DSS:

• La identificación es la atribución de una identidad única a una persona o sistema.
• La autenticación es el proceso de verificación de la identidad del usuario/sistema. Al solicitar acceso y presentar una identificación de usuario/sistema único, el usuario/sistema proporciona un conjunto de datos privados a los que solo él tiene acceso o conocimiento. Para este proceso se emplea la validación de uno o más de los siguientes factores:
  • Algo que se sabe (something you know – SYK), como una contraseña,
  • Algo que se tiene (something you have – SYH), como un token o una tarjeta inteligente (smart card),
  • Algo que se es (something you are -SYA), como un control biométrico.

Factores de autenticación. Fuente: https://www.yubion.com

• La autorización es el proceso de definir los recursos específicos que necesita un usuario/sistema (acceso) y determinar los privilegios sobre dichos recursos. La gestión de la autorización debe estar basada en los siguientes criterios:
  • «Necesidad de saber» (Need-to-know) se refiere a proporcionar acceso solo a la menor cantidad de datos necesarios para realizar un trabajo.
  • Los «mínimos privilegios» (Least privileges) se refieren a proporcionar solo el nivel mínimo de privilegios necesarios para realizar un trabajo.
  • La “separación de responsabilidades” (Separation of duties) permiten dividir las funciones de misión crítica entre diferentes individuos y/o funciones, define roles y responsabilidades para cada individuo o rol y garantiza que el personal de seguridad que administra las funciones de control de acceso no administre también las funciones de auditoría para evitar conflictos de interés empleando el control dual y el conocimiento dividido:
    • Control dual (dual control): Un proceso que utiliza dos o más entidades separadas (normalmente personas) que operan de forma concertada para proteger funciones o información sensibles. Ninguna entidad por sí sola puede acceder o utilizar el material.
    • Conocimiento dividido (Split knowledge): Separación de los datos o la información en dos o más partes, cada una de las cuales se mantiene constantemente bajo el control de personas o equipos autorizados por separado, de modo que ninguna persona o equipo conozca la totalidad de los datos.

La relación entre estos tres importantes conceptos es sencilla:

• La identificación proporciona unicidad
• La autenticación proporciona validez
• La autorización proporciona control

La gestión de estos tres conceptos se denomina “Identidad y gestión de acceso” (Identity and Access Management – IAM) y sus reglas de implementación son evaluadas en los controles de estos requerimientos 7, 8 y 9 de PCI DSS.

1. Todos los sistemas de MFA son aceptables, pero algunos son más aceptables que otros

Parafraseando la novela de George Orwell, «Rebelión en la granja«, desde el punto de vista conceptual, el uso de dos o más factores de autenticación se considera como autenticación multifactor (MFA) en el estándar PCI DSS. No obstante, dependiendo de los factores de autenticación involucrados, el escenario a proteger y otros elementos externos a la autenticación (uso de tiempos límite (timeouts), bloqueos por intentos fallidos, canales de transmisión de datos, etc.), un sistema de autenticación MFA puede ser más robusto que otro. No es lo mismo usar una contraseña (algo que se sabe) y un código One-Time Password (OTP) enviado al correo electrónico (algo que se tiene) que emplear un sistema de autenticación basado en dispositivos físicos seguros (algo que se tiene) en conjunto con biometría (algo que se es). Ambos cumplen con los criterios de MFA (uso de dos elementos de autenticación distintos), pero, como se puede concluir fácilmente, la seguridad del primero no se puede comparar con la seguridad del segundo…

Siendo así, es importante diferenciar entre el cumplimiento y la seguridad. Mientras que el uso de dos o más factores se puede usar en PCI DSS como MFA y es totalmente aceptable (cumplimiento), su seguridad puede ser más o menos robusta dependiendo de otros aspectos que deben ser evaluados por la entidad ANTES de proceder con la implementación del sistema de autenticación y por el QSA/ISA durante la evaluación de cumplimiento. Entre estos aspectos se destacan la resistencia a diferentes tipos de ataques y vulnerabilidades como phishing, compromiso de los autenticadores (aplicaciones o dispositivos que proveen credenciales de autenticación), compromiso de cuentas, ataques de relay (attacker-in-the-middle), vulnerabilidades criptográficas, compromiso de secretos y/o ataques de fuerza bruta.

Para ello, en esta nueva guía se incluye una tabla muy interesante que analiza los diferentes tipos de autenticación y su nivel de seguridad, organizados por fortaleza. En este caso, esta tabla se puede usar como referencia para escoger los métodos de autenticación a ser empleados en el proceso de MFA y sus riesgos asociados para adaptarlos al entorno a proteger:

Fortaleza de cada factor de autenticación

2. Uso de PIN: ¿Es aceptable?

Durante muchos años nos han inculcado que para que una contraseña (algo que se) sea «robusta», debe cumplir con una serie de controles a nivel de complejidad, expiración (cambio/rotación), historial (reuso), etc. Algunos criterios han cambiado a lo largo del tiempo (como, por ejemplo, la longitud y los periodos de cambio de las contraseñas en la actualización de las guías del NIST SP 800-63 Digital Identity Guidelines en 2025).

No obstante, cuando pensamos en un número de identificación personal (Personal Identification Number – PIN), lo que se nos viene a la cabeza es un conjunto de dígitos con una longitud corta que – ni de lejos – podría cumplir con los controles de seguridad aplicables a una contraseña. Pero, aún  así, el PCI SSC permite el uso de un PIN como elemento de autenticación. Pero, ¿cómo es esto posible?

De acuerdo con esta nueva guía (apartado Use of PINs and Other Low Entropy Knowledge-Based Factor), el uso de un PIN (como, por ejemplo, cuatro números escogidos por el usuario) puede ser aceptable siempre y cuando se agreguen controles adicionales tales como bloqueos después de una cierta cantidad de intentos fallidos (para prevenir ataques de fuerza bruta), acciones específicas después de superar el umbral de intentos fallidos, almacenamiento seguro, etc.

Cuando estos controles adicionales no pueden ser implementados, entonces el PIN debe cumplir con los controles aplicables a las contraseñas.

3. Multi-Step vs. Multi-Factor: Cambios en el criterio de aceptación

Uno de los conceptos que generó mayores debates (e incluso obligó a implementaciones específicas para lograr su cumplimiento, como fue el caso de Fortinet FortiAuthenticator y PCI DSS 3.2) fue el de la diferencia entre autenticación en varios pasos (multi-step) y autenticación multifactor.

En la guía de 2017 se estipulaba lo siguiente:

PCI DSS requires that all factors in multi-factor authentication be verified prior to the authentication mechanism granting the requested access. Moreover, no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented. If an unauthorized user can deduce the validity of any individual authentication factor, the overall authentication process becomes a collection of subsequent, single-factor authentication steps, even if a different factor is used for each step. For example, if an individual submits credentials (e.g., username/password) that, once successfully validated, lead to the presentation of the second factor for validation (e.g., biometric), this would be considered “multi-step” authentication.

De acuerdo con ello, TODOS los factores de autenticación deberían ser evaluados ANTES de dar acceso al usuario y NO SE PODÍA ofrecer ninguna notificación al usuario relacionada con la validación exitosa o errónea de estos factores. Sin embargo, en PCI DSS v4.x y en esta nueva guía de autenticación, se aclara lo siguiente:

PCI DSS v4.x requires the success of all authentication factors before access is granted. MFA implementations that indicate the success of one factor prior to presenting any subsequent factor(s) meet applicable PCI DSS requirements for MFA. However, access cannot be provided until success of all factors is verified.

Como se puede observar, la diferencia es sutil pero muy importante: Es aceptable que se notifique si uno de los factores de autenticación es exitoso ANTES de solicitarle al usuario el siguiente factor. Esto también se enfatiza en la FAQ #1584: For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?

Aunque, lo más extraño de todo esto, es que esa restricción del 2017 relacionada con la notificación de éxito o error en la presentación de los factores de autenticación y que ahora se permite, se ha movido a una mejor práctica:

It is a best practice that systems either 1) provide no feedback about the success of any factor until all factors are provided, or 2) authenticate with a session-unique factor (for example, a one-time password (OTP) or phishing-resistant factor) before authenticating any factor that is the same across different sessions (such as a password).

En conclusión: se acepta si se notifica el éxito en la presentación de un factor PERO mejor si esto no se hace, ya que es una buena práctica… ‍¯\_(ツ)_/¯

4. Sistemas resistentes a Phishing: La gran apuesta de PCI DSS

Otro concepto nuevo que se ha agregado a esta nueva guía y que no se contemplaba en la guía de MFA de 2017 es el de factores de autenticación resistentes a ataques de phishing (Phishing-Resistant Authentication Factors). Mediante el uso de este tipo de sistemas de autenticación se minimiza la capacidad de un atacante de capturar las credenciales a través de ataques de phishing para posteriormente reutilizarlas en ataques de replay (en el cual el atacante intercepta las credenciales de un usuario para luego reenviarlas y obtener acceso) o relay (man-in-the-middle). Esta implementación depende de funciones criptográficas que garantizan que no se comparten credenciales de autenticación sin primero validar el sistema de autenticación que está haciendo la petición. Esto se logra mediante la validación de posesión de claves criptográficas específicas por parte de los sistemas involucrados, por lo que estos sistemas son catalogados como «algo que se tiene» (SYH).

Generalmente, estas claves criptográficas se almacenan en dispositivos de seguridad que, por sí solos, no se consideran MFA. En estos casos, este factor de autenticación debe combinarse con otro elemento de autenticación (como un PIN o una contraseña) para poder ser considerado como tal.

Modelo de funcionamiento de sistemas de autenticación resistentes a phishing

El uso de sistemas de autenticación resistentes a phishing no es obligatorio. No obstante, su uso sí que tiene algunas ventajas en el cumplimiento de PCI DSS, como por ejemplo en la implementación del control 8.4.2 MFA is implemented for all non-console access into the CDE. En este caso en particular, este requisito no aplica si las cuentas de usuario son autenticadas únicamente con factores de autenticación resistentes a phishing (incluyendo sistemas implementados de acuerdo con FIDO2).

5. Autenticación de sesiones: Lo que sigue después de MFA

Una vez que la identidad del usuario ha sido comprobada en un proceso de autenticación (usando MFA) y sus privilegios han sido asignados (autorización), se establece una relación de confianza entre los sistemas vinculados al proceso que se representa en una sesión. En peticiones subsecuentes, en vez de volver a validar una y otra vez al usuario empleando MFA (lo cual no sería práctico ni operativo), se valida la sesión asociada. Por ello, los atacantes, en vez de enfocarse en el proceso de autenticación (reforzado mediante MFA), vuelcan sus esfuerzos en obtener las credenciales vinculadas a la sesión.

Lo interesante en este punto es que el estándar PCI DSS incluye controles para reforzar el proceso de gestión de identidades y autenticación (incluyendo MFA) pero, de forma explícita, no estipula controles para la protección de sesiones. En la guía de autenticación se incluyen una serie de mejores prácticas para minimizar potenciales ataques a sesiones, entr los cuales se encuentran:

• Una vez superado el proceso de autenticación, las sesiones se deberían vincular a usuarios y/o dispositivos. De esta manera, si un atacante logra comprometer una sesión, no podrá emplearla dada que estaría enlazada a un dispositivo (ordenador, móvil, etc.) o a un usuario específico.
• Implementación de controles de time-out.
• Uso de canales de comunicación seguros que agreguen controles adicionales de protección, como TLS.

Muchos de estos conceptos se enmarcan dentro de la estrategia de Zero Trust Architectures (ZTA), en la cual se asume que no hay una confianza implícita otorgada a los activos o cuentas de usuario basándose únicamente en su ubicación física o en la propiedad de los activos.

Bonus: Configuración de contraseñas en autenticación MFA

A pesar de todos los esfuerzos para implementar procesos de autenticación que no estén basados en contraseñas (passwordless authentication), las contraseñas siguen siendo un factor de autenticación ampliamente usado y que no podrá ser remplazado en el corto plazo.

Los métodos para vulnerar la seguridad proporcionada por una contraseña son ampliamente conocidos y – por ello – es imprescindible que cuando se haga uso de estos elementos se implementen políticas de gestión de contraseñas, incluyendo protección durante su almacenamiento y transmisión, bloqueo por intentos fallidos, procesos seguros de cambio y asignación, complejidad, historial de uso y periodicidad para cambiarlas.

No obstante, cuando una contraseña se emplea acompañada de otro factor de autenticación, no es necesario que se cambie cada 90 días, como lo estipula el requisito 8.3.9 (Passwords/passphrases are changed at least once every 90 days). Esta es la única excepción en la implementación de la política de contraseñas. En todos los demás casos en los cuales la contraseña se use como único factor de autenticación, todos los controles (del 8.3.1 al 8.3.10) son aplicables.

Comentarios finales

Aparte de esto cinco conceptos clave, esta nueva guía de autenticación explica en detalle nuevos conceptos introducidos en PCI DSS v4, tales como las cadenas de MFA (MFA chains), en las cuales se requiere autenticación MFA cuando se accede de forma remota desde fuera de la red de la entidad (req. 8.4.3) y cuando se accede al CDE (req. 8.4.1/8.4.2), tal y como se había explicado anteriormente en PCI Hispano:

Procesos de autenticación en PCI DSS

Otro valor adicional proporcionado por esta guía es esta tabla que incluye los tipos de autenticación y su aplicabilidad en PCI DSS, solucionando muchas de las dudas que existían en la implementación de MFA en las versiones de PCI DSS anteriores:

Tipos de autenticación y su aplicabilidad en PCI DSS

Finalmente, se incluyen seis (6) escenarios de implementación de procesos de autenticación, en donde se analizan sus ventajas y problemas, así como su cumplimiento y alineación con los criterios de PCI DSS, especialmente MFA.

En conclusión, este es un documento imprescindible para cualquier entidad que se encuentre afectada por PCI DSS que debe ser empleado como referencia básica para analizar, escoger y configurar sistemas de autenticación. Igualmente, todos los asesores QSA/ISA deben estar familiarizados con la terminología y conceptos explicados en esta guía antes de proceder con una evaluación de cumplimiento.