Por qué la MFA tradicional sigue perdiendo frente a los ataques adversary-in-the-middle

La autenticación multifactor (MFA) sigue siendo uno de los avances más útiles frente a las contraseñas solas. Bloquea la mayor parte del stuffing automatizado y muchas páginas de phishing simples que solo capturan una contraseña. Pero no es a prueba de phishing. En abril de 2026, el National Cyber Security Centre (NCSC) del Reino Unido comparó la MFA tradicional con las credenciales FIDO2 y las passkeys para uso personal y encontró una brecha clara: el phishing adversary-in-the-middle (AitM) sigue derrotando la combinación de contraseña con SMS, TOTP, aprobaciones push o códigos por correo, mientras que FIDO2 no.

Este artículo explica esa brecha en términos prácticos y por qué pasar las cuentas de alto valor a passkeys importa más que añadir otro código SMS.

La MFA frenó el stuffing, no los proxies de phishing

El credential stuffing funciona porque la gente reutiliza contraseñas. Cuando una contraseña se filtra en una brecha, los atacantes la prueban en correo, bancos, tiendas y la nube. Un segundo factor corta ese patrón: la contraseña robada ya no basta.

Ese éxito creó un modelo mental engañoso. Muchos oyeron que la MFA «detiene el phishing». Frente a una página falsa estática que solo captura una contraseña, la MFA suele ayudar. Frente a un proxy de phishing en vivo entre usted y el sitio real, la MFA tradicional suele fallar. Los informes del sector suelen citar la MFA como bloqueadora de la gran mayoría de tomas de cuenta automatizadas; esa cifra describe stuffing y robos poco sofisticados, no el robo de sesión AitM.

Cómo funciona el phishing adversary-in-the-middle

En un ataque AitM, la víctima llega a un sitio de apariencia legítima controlado por el atacante. No es un formulario simple. Es un proxy inverso que reenvía cada petición al servicio real en tiempo real.

Usted introduce usuario y contraseña. El proxy los envía al sitio real. El sitio real pide un segundo factor. Usted escribe el código SMS, el código del autenticador, el OTP por correo o aprueba un aviso push. El proxy también lo reenvía. Cuando el sitio real emite una cookie o token de sesión, el atacante la copia y toma la sesión autenticada —a menudo sin necesitar la contraseña después.

• El atacante no necesita «romper» la criptografía de la MFA. Espera a que usted complete un inicio de sesión válido.
• El artefacto robado suele ser la cookie de sesión o el token bearer, no solo la contraseña.
• Herramientas al estilo Evilginx hicieron que esta técnica esté ampliamente disponible para delincuentes.

Por qué SMS, TOTP, push y OTP por correo fallan todos frente al AitM

Estos segundos factores demuestran que intervino alguien capaz de recibir un mensaje, leer un código rotativo o pulsar «Aprobar». No demuestran que el navegador que habla con el sitio real sea el suyo.

• OTP por SMS: el código es un secreto compartido de corta duración. Si lo escribe en una página proxificada, el atacante obtiene un inicio de sesión válido.
• TOTP del autenticador: el mismo problema. El código de seis dígitos es válido tanto para el sitio real como para el proxy durante una ventana breve.
• Aprobaciones push: aprobar «¿Fue usted?» completa el inicio de sesión del atacante, salvo que el aviso incluya number matching fuerte y usted revise con cuidado el origen.
• OTP por correo: otro código reenviable. Si el atacante ya tiene la contraseña y puede forzar el segundo paso, la entrega por correo no vincula el inicio de sesión al origen real.

Ataques de fatiga y SIM-swap como fallos secundarios de la MFA tradicional

El AitM no es la única forma en que falla la MFA tradicional. Los ataques de fatiga saturan las notificaciones push hasta que alguien acepta una para que pare el ruido. El SIM-swap y la interceptación de SMS roban códigos antes de que le lleguen.

La comparación del NCSC trata estos escenarios como motivos adicionales por los que la MFA tradicional es más débil que FIDO2 a lo largo del ciclo de vida de las credenciales. Aunque nunca pulse un enlace de phishing, la fatiga push y el abuso de SIM siguen siendo amenazas personales realistas.

• La fatiga push funciona porque «Aprobar» es fácil y el aviso a menudo carece de contexto claro.
• El SIM-swap apunta al número que recibe los códigos SMS, no a la contraseña en sí.
• Estos fallos refuerzan la misma lección que el AitM: un factor que se puede coaccionar, retransmitir o desviar no es resistente al phishing.

Por qué FIDO2 y las passkeys resisten el AitM

Las credenciales FIDO2 / WebAuthn —incluidas las passkeys— están vinculadas al origen real del sitio. Su autenticador no completará una ceremonia para evil-bank.example cuando la credencial pertenece a bank.example.

La clave privada nunca sale del autenticador (o del sync fabric protegido en passkeys sincronizadas). El sitio recibe una firma sobre un desafío que incluye información de origen, no un secreto reutilizable que se pueda escribir en un proxy.

Por eso la tabla del NCSC marca el phishing adversary-in-the-middle como siempre exitoso contra la MFA tradicional y nunca exitoso contra las credenciales FIDO2 en el modelo de amenaza personal que evaluaron.

• La vinculación al origen impide el uso de la credencial en dominios de apariencia similar.
• No existe un OTP corto que el atacante pueda retransmitir en tiempo real.
• El robo de sesión mediante una 2SV proxificada ya no sigue el mismo camino de ataque.

La trampa de la transición: degradación MFA mientras la contraseña sigue como respaldo

Aunque un servicio admita passkeys, muchas cuentas siguen conservando contraseña más una MFA más débil como respaldo. Los atacantes lo saben. Los ataques de degradación MFA empujan a la víctima hacia el camino más débil: restablecer contraseña, «iniciar sesión de otra forma», SMS en lugar de llave de seguridad, o un flujo de recuperación que nunca muestra el aviso de passkey.

Durante la larga coexistencia de contraseñas y passkeys, el camino más débil permitido suele decidir el nivel real de seguridad. Registrar una passkey solo ayuda si también resiste la UX de degradación y trata las opciones de recuperación con el mismo cuidado que el inicio de sesión principal.

Qué hacer ahora

No necesita esperar a que cada sitio deje las contraseñas. Priorice las cuentas que desbloquean todo lo demás y luego endurezca el resto.

• Prefiera passkeys o llaves de seguridad para correo, gestor de contraseñas, banca, nube y cuentas de desarrollador. Empiece con nuestra guía de passkeys.
• Donde siga la MFA push, use number matching y trate los avisos inesperados como hostiles.
• Evite el SMS como segundo factor principal cuando exista una mejor opción.
• Hasta que una cuenta admita passkeys, use una contraseña larga y única de un gestor: el stuffing sigue prosperando con la reutilización.
• Revise las opciones de recuperación para que «olvidé la contraseña» o «probar otro método» no borren en silencio la resistencia al phishing.