1. Autenticación multifactor

La autenticación multifactor o MFA exige al usuario demostrar su identidad con dos o más factores de categorías distintas, de modo que el robo de uno no baste para suplantarlo. Es la medida individual más eficaz contra el compromiso de credenciales, porque neutraliza ataques que dependen exclusivamente de la contraseña: pulverización, relleno de credenciales o phishing de contraseñas.

1.1. Dos factores, dos pasos y multifactor

  • 2FA o doble factor: exactamente dos factores de categorías distintas. Es la forma más habitual de MFA.

  • MFA: dos o más factores. En la práctica se usa como sinónimo ampliado de 2FA.

  • Verificación en dos pasos: dos comprobaciones sucesivas que pueden ser del mismo factor. Una contraseña seguida de una pregunta secreta son dos pasos, pero un único factor, y no ofrecen la protección de un MFA.

La independencia de los factores es lo que importa

Combinar una contraseña con un código enviado al mismo teléfono en el que se ha iniciado sesión reduce la independencia: un único dispositivo comprometido entrega ambos. La calidad de un MFA depende de qué ataque neutraliza cada factor, no de cuántas pantallas atraviesa el usuario.

1.2. Autenticación resistente al phishing

Un MFA con códigos que el usuario teclea, ya sean de una aplicación, de un mensaje o de una llave, sigue siendo vulnerable a un atacante que se interpone entre el usuario y el servicio. Un MFA resistente al phishing impide que una web falsa obtenga algo reutilizable: los autenticadores FIDO2 y las tarjetas inteligentes con autenticación mutua validan el origen y no producen secretos que el usuario pueda entregar. Las agencias de ciberseguridad, como CISA, recomiendan priorizarlos para las cuentas más expuestas.

2. Niveles de garantía de la autenticación

NIST SP 800-63B-4 clasifica la confianza en una autenticación en tres niveles de garantía, AAL, que exigen cada vez más:

Nivel Qué exige Resistencia al phishing

AAL1

Un factor o más. Basta una contraseña, por ejemplo

No exigida

AAL2

Dos factores: un autenticador multifactor, o un autenticador físico más contraseña o biometría

El servicio debe ofrecer al menos una opción resistente al phishing

AAL3

Autenticación criptográfica multifactor, con una clave privada no exportable

Exigida

La norma europea eIDAS define una escala equivalente de tres niveles de seguridad de los medios de identificación electrónica: bajo, sustancial y alto. Elegir el nivel adecuado es una decisión de riesgo:

Recurso protegido Nivel orientativo Ejemplo de autenticación

Servicio informativo sin datos personales

AAL1

Contraseña robusta

Correo corporativo, aplicaciones de empresa

AAL2

Contraseña y aplicación TOTP; mejor, llave FIDO2

Administración de sistemas, datos muy sensibles

AAL3

Llave FIDO2 o tarjeta inteligente

3. Diseño de políticas MFA

Una política de MFA eficaz equilibra seguridad y usabilidad: si es incómoda, los usuarios buscan atajos y la organización acaba con excepciones que anulan su valor.

3.1. A quién y dónde aplicarla

  1. Cuentas privilegiadas y administradores: siempre, con autenticadores resistentes al phishing.

  2. Accesos remotos y VPN: siempre, porque están expuestos a Internet.

  3. Correo, nube y aplicaciones SaaS: siempre, ya que concentran los datos y se usan para restablecer otras cuentas.

  4. Accesos desde la red interna a recursos de poco riesgo: puede relajarse mediante la autenticación adaptativa.

3.2. Decisiones de diseño

Cuestión Recomendación Justificación

Métodos permitidos

Ofrecer un abanico jerarquizado y retirar los más débiles, como SMS y voz

Los usuarios eligen el más cómodo, y el atacante, el más débil

Alta del autenticador

Presencial o verificada por un canal independiente

Es el momento en que un atacante puede registrar el suyo

Recuperación

Con la misma robustez que la autenticación, con aviso al usuario

Es el camino alternativo que atacarán

Autenticadores de reserva

Registrar al menos dos por usuario

Evita bloqueos y recuperaciones inseguras

Cuentas de servicio

Sin MFA interactivo: usar claves o certificados, con origen restringido

Las aplicaciones no pueden responder a un reto humano

Cuentas de emergencia

Llaves de seguridad custodiadas fuera de línea, con alertas en cada uso

Permiten recuperar el acceso si falla el proveedor de MFA

Duración de la sesión

Reautenticar ante operaciones sensibles y tras periodos largos

Limita el valor de una sesión robada

«Recordar este dispositivo»

Plazos cortos y ligados a un dispositivo gestionado

Reduce la fricción sin eliminar la exigencia

3.3. Usabilidad

La mejor protección contra la resistencia de los usuarios es reducir la fricción: combinar el inicio de sesión único con claves de acceso, de modo que un solo gesto sustituya a la contraseña y al segundo factor. Conviene medir la cobertura de MFA por colectivo, la tasa de fallos y las solicitudes de soporte, y atender a los usuarios con necesidades de accesibilidad con alternativas equivalentes.

3.4. Requisitos normativos

En muchos sectores la autenticación reforzada no es una decisión técnica, sino una obligación legal. Antes de diseñar la política conviene saber cuál de estas normas resulta aplicable, porque fija el mínimo exigible.

Norma Ámbito de aplicación Qué exige

ENS, Real Decreto 311/2022

Sector público español y quienes le prestan servicios

Las medidas op.acc.5, para usuarios externos, y op.acc.6, para los de la organización, regulan el mecanismo de autenticación. Para los usuarios de la organización, el acceso desde zonas no controladas, como internet, exige un segundo factor, ya sea una contraseña de un solo uso que complemente a la contraseña habitual o un certificado protegido por PIN o por biometría. Para los usuarios externos, esa exigencia aparece a partir del nivel medio

PSD2 y su Reglamento Delegado (UE) 2018/389

Servicios de pago en la Unión Europea

Autenticación reforzada de cliente con dos elementos independientes de categorías distintas, de modo que el compromiso de uno no comprometa al otro. En los pagos remotos exige además vinculación dinámica, es decir, que el código de autenticación quede ligado al importe y al beneficiario concretos de la operación. Aplicable desde el 14 de septiembre de 2019

PCI DSS, versión 4.0.1

Quien almacena, procesa o transmite datos de tarjetas de pago

El requisito 8.4.2 exige autenticación multifactor para todo acceso al entorno de datos de titulares de tarjeta, y no solo para las cuentas administrativas como en versiones anteriores. Es de obligado cumplimiento desde el 31 de marzo de 2025

eIDAS, Reglamento (UE) 910/2014

Identificación electrónica transfronteriza

Niveles de seguridad bajo, sustancial y alto, equivalentes a los niveles de garantía de la sección 2

De este panorama conviene retener dos ideas. La primera es que la norma marca un suelo y no un techo, de modo que nada impide exigir un autenticador resistente al phishing allí donde el texto legal se conforma con una contraseña de un solo uso, que ya se ha visto que no lo resiste. La segunda es que el ENS introduce un criterio que merece la pena adoptar aunque no se esté obligado a cumplirlo, el de graduar la exigencia según la zona desde la que se accede, que es la misma idea de la autenticación adaptativa de la sección siguiente aplicada a la red de origen.

4. Autenticación adaptativa o basada en riesgo

La autenticación adaptativa o basada en riesgo, RBA, decide en cada intento cuánta prueba exigir según el contexto. Un acceso habitual no se interrumpe y uno sospechoso se refuerza. Reduce la fricción en el caso normal y concentra la exigencia donde hace falta.

4.1. Señales

  • Identidad: pertenencia a grupos privilegiados, antigüedad de la cuenta, incidentes previos.

  • Dispositivo: si es conocido, si está gestionado y su estado de seguridad.

  • Red y ubicación: país, red corporativa o pública, reputación de la dirección.

  • Tiempo y comportamiento: hora habitual, velocidad de desplazamiento imposible entre dos accesos, patrones de uso.

  • Recurso: la sensibilidad de lo que se solicita.

4.2. Decisión y acción

El motor combina las señales en una puntuación de riesgo o en reglas condicionales y elige una acción:

Riesgo Acción habitual

Bajo

Permitir con los factores normales

Medio

Exigir un factor adicional o un método más robusto, lo que se denomina step-up

Alto

Bloquear, limitar el acceso a solo lectura o exigir la intervención del soporte

Muy alto

Bloquear y generar una alerta de seguridad

4.3. Riesgos y límites

  • Falsos positivos y negativos: un empleado de viaje se bloquea; un atacante con un proxy en el país del usuario pasa desapercibido.

  • Opacidad: si el usuario no entiende por qué se le exige algo, desconfía o busca atajos. Conviene registrar el motivo de cada decisión.

  • Privacidad: las señales de comportamiento son datos personales, y su recogida debe ser proporcionada y justificada.

  • No sustituye al MFA: es una capa adicional, no una razón para eliminar factores.

Este modelo es la aplicación práctica del principio de verificar de forma continua propio de las arquitecturas de confianza cero, y se implementa en el Ejercicio 2.

Con los conceptos explicados hasta aquí, ya puede realizar el Ejercicio 2. Un motor de decisión basado en riesgo y el Ejercicio 3. Diseño de una política de MFA.

5. Ataques contra la autenticación y el MFA

Los atacantes han adaptado sus técnicas al MFA. No lo rompen: lo rodean, aprovechando al usuario, el proceso de recuperación o la sesión posterior.

Ataque Técnica ATT&CK Cómo funciona Defensa principal

Fatiga de MFA

T1621

Con una contraseña robada, el atacante provoca solicitudes repetidas hasta que el usuario acepta

Coincidencia de número, límite de solicitudes, alertas

Phishing con intermediario, AiTM

T1557

Un servidor falso retransmite la autenticación al sitio real y captura la sesión resultante

Autenticadores resistentes al phishing; vinculación de la sesión al dispositivo

Robo de la cookie o token de sesión

T1539

Se roba una sesión ya autenticada, con el segundo factor superado

Sesiones cortas y ligadas al dispositivo; reautenticación

Interceptación de códigos

T1111

Se capturan o retransmiten los códigos de un solo uso

Autenticadores criptográficos; no usar SMS

Registro de un autenticador del atacante

T1098.005

Tras un acceso inicial, se añade un dispositivo propio como segundo factor

Alertar y exigir reautenticación al registrar métodos

Ingeniería social contra la recuperación

T1556

Se engaña a soporte técnico o se abusa de la recuperación para eliminar el MFA

Verificación robusta de identidad, aviso al usuario, doble aprobación

Pass-the-Hash

T1550.002

Se reutiliza el hash NTLM de una cuenta sin conocer la contraseña

Limitar NTLM, protección de credenciales, privilegios mínimos

Kerberoasting, Golden Ticket

T1558

Ataques contra Kerberos, estudiados en el capítulo de autenticación centralizada

Contraseñas robustas de cuentas de servicio, protección del KDC

Pulverización y relleno de credenciales

T1110.003, T1110.004

Estudiados en el capítulo del factor de conocimiento

MFA, listas de bloqueo, detección

5.1. La fatiga de MFA

  1. El atacante obtiene una contraseña mediante phishing, relleno de credenciales o una filtración.

  2. Intenta iniciar sesión repetidamente, y cada intento genera una notificación push en el teléfono de la víctima, a veces de madrugada.

  3. El usuario, cansado o confundido, acepta para que cesen, o lo hace tras una llamada del atacante que se hace pasar por el soporte técnico.

La clave de la detección es el patrón: muchos rechazos o solicitudes ignoradas seguidas de una aprobación. Las defensas son técnicas, con coincidencia de número y mostrando el contexto de la solicitud, y organizativas, con formación y un procedimiento claro para informar de solicitudes inesperadas. La detección se practica en el Ejercicio 1.

5.2. El ataque con intermediario

  1. El usuario recibe un mensaje con un enlace a un sitio que imita al servicio real.

  2. El sitio falso actúa de proxy inverso: reenvía al servicio real todo lo que el usuario teclea, incluida la contraseña y el código del segundo factor.

  3. El servicio real autentica al atacante a través del proxy y entrega una sesión, que el proxy captura.

  4. El atacante reutiliza la sesión, sin necesidad de volver a pasar por el MFA.

Este ataque neutraliza los códigos de un solo uso, las notificaciones y los SMS, pero no los autenticadores resistentes al phishing: como se explicó en el capítulo de autenticación criptográfica, el autenticador verifica el origen y no responde ante un dominio distinto del legítimo. Es el motivo principal por el que las organizaciones migran a FIDO2 en cuentas críticas.

6. Detección y respuesta

Las defensas preventivas se complementan con una vigilancia de los eventos de autenticación. Conviene registrar y enviar a un sistema centralizado:

  • Los inicios de sesión correctos y fallidos, con método, origen y dispositivo.

  • Las solicitudes de segundo factor y su resultado.

  • El alta, cambio y eliminación de métodos de autenticación.

  • Los restablecimientos de contraseña y de MFA.

  • El uso de cuentas de emergencia y privilegiadas.

Indicador Qué sugiere Respuesta

Muchas solicitudes de MFA rechazadas y una aprobación

Fatiga de MFA

Contactar al usuario, revocar sesiones y cambiar la credencial

Registro de un nuevo método de MFA desde un origen nuevo

Persistencia del atacante

Eliminar el método y reautenticar con un factor fuerte

Sesión usada desde dos países en poco tiempo

Sesión robada

Revocar sesiones y tokens

Muchos usuarios distintos fallando desde un mismo origen

Pulverización

Bloquear el origen y alertar

Uso de una cuenta de emergencia

Acceso extraordinario

Verificar la autorización de inmediato

Cuando se confirma un compromiso, la respuesta mínima es: revocar sesiones y tokens, restablecer la credencial y los métodos de MFA, eliminar los autenticadores desconocidos y revisar qué hizo la cuenta durante el periodo de acceso.

7. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu o Debian de pruebas. Todos los archivos se crean en ~/lab_mfa. El último ejercicio elimina todo lo creado.

Nº Ejercicio Competencia que desarrolla

1

Detectar la fatiga de MFA

Identificar el patrón de ataque en los registros

2

Un motor de decisión basado en riesgo

Implementar una política adaptativa sencilla

3

Diseño de una política de MFA

Aplicar los criterios de diseño a un caso

4

Limpieza del entorno

Revertir los cambios realizados

7.1. Ejercicio 1. Detectar la fatiga de MFA

Realice los siguientes pasos:

  1. Cree el directorio de trabajo y el registro de muestra push.log, con el resultado de las solicitudes de autenticación por notificación:

    mkdir -p ~/lab_mfa && cd ~/lab_mfa
cat > push.log << 'EOF'
03:12:00 maria denegado
03:12:40 maria denegado
03:13:15 maria denegado
03:13:50 maria ignorado
03:14:20 maria denegado
03:14:55 maria denegado
03:15:30 maria denegado
03:16:10 maria aprobado
09:02:11 juan aprobado
09:30:00 lucia denegado
09:31:10 lucia aprobado
EOF

  2. Escriba una orden awk que cuente, para cada usuario, los rechazos o solicitudes ignoradas consecutivas y emita una alerta si la siguiente aprobación llega tras cinco o más.

  3. Razone por qué lucia no genera alerta aunque también rechazó una solicitud, y qué falsos positivos y falsos negativos tendría un umbral de cinco.

  4. Proponga tres medidas técnicas que hubieran impedido el ataque contra maria, además de la detección.

7.2. Ejercicio 2. Un motor de decisión basado en riesgo

Realice los siguientes pasos:

  1. Cree el archivo accesos.csv, con el usuario, el país, si el dispositivo es conocido, la hora y la reputación de la dirección de origen de cuatro intentos de acceso:

    cd ~/lab_mfa
cat > accesos.csv << 'EOF'
maria,ES,si,10,limpia
juan,ES,no,23,limpia
lucia,RU,no,3,mala
pedro,FR,si,14,limpia
EOF

  2. Escriba un script awk que calcule una puntuación de riesgo con estas reglas: 30 puntos si el país no es ES, 25 si el dispositivo es desconocido, 15 si la hora está fuera de 7 a 21 y 40 si la reputación es mala. La decisión es permitir con menos de 30, exigir MFA adicional de 30 a 59 y bloquear con 60 o más.

  3. Compruebe las decisiones: maria debe poder acceder, juan y pedro deben afrontar un reto adicional y lucia debe ser bloqueada. Explique por qué pedro recibe un reto aunque su dispositivo es conocido, y qué ocurriría para un empleado de viaje.

  4. Modifique las reglas para que los usuarios de un grupo privilegiado, como maria, tengan una puntuación base de 20, y razone el efecto sobre la usabilidad y la seguridad.

7.3. Ejercicio 3. Diseño de una política de MFA

Una empresa de 300 empleados quiere extender el MFA a todos los accesos, tiene 8 administradores de sistemas, 40 trabajadores en remoto con VPN, aplicaciones en la nube con inicio de sesión único y una aplicación heredada que no admite segundo factor.

Realice los siguientes pasos:

  1. Complete una tabla con cuatro columnas: colectivo, método mínimo, método recomendado y justificación, para administradores, trabajadores en remoto y resto de empleados.

  2. Proponga una solución para la aplicación heredada que no admite MFA, indicando qué control compensatorio aplicaría.

  3. Diseñe el procedimiento de recuperación cuando un empleado pierde su teléfono, indicando cómo verificaría su identidad y qué avisos generaría.

  4. Defina tres indicadores para medir el éxito del despliegue.

7.4. Ejercicio 4. Limpieza del entorno

  1. Elimine el directorio de trabajo.

8. Referencias

9. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.