MFA resistente al phishing: por qué no todo doble factor es igual
La autenticación multifactor no es una sola cosa. La distancia entre un código de un solo uso enviado por SMS y un passkey respaldado por hardware es la diferencia entre ralentizar a un atacante y detenerlo por completo. Esta es la distinción entre MFA phishable y MFA resistente al phishing.
Por qué la mayoría de la MFA sigue siendo phishable
El problema de los códigos y las peticiones push es que el segundo factor es un secreto compartido que la persona puede entregar. Si un usuario puede leer un código y teclearlo en una página, puede ser engañado para teclearlo en la página de un atacante.
- Códigos SMS / TOTP: un proxy de atacante en el medio (AiTM) como Evilginx presenta un clon de inicio de sesión idéntico, retransmite las credenciales y el OTP en tiempo real y captura la cookie de sesión resultante. El código válido no sirve de nada.
- Notificaciones push: vulnerables a la fatiga de MFA / bombardeo de peticiones: aprobaciones repetidas hasta que un usuario cansado pulsa «Aprobar».
- Intercambio de SIM (SIM swapping): pasa el número de la víctima a la SIM de un atacante y derrota el SMS por completo.
La coincidencia de números y el geocontexto en el push ayudan, pero son mitigaciones sobre un diseño fundamentalmente phishable.
Qué hace a la MFA resistente al phishing
La MFA resistente al phishing saca a la persona de la decisión de confianza. Importan dos propiedades:
- Vinculación al origen: la credencial está atada criptográficamente al origen web exacto para el que se registró. Un dominio parecido o proxy simplemente no coincide, así que la autenticación falla en silencio.
- Sin secreto compartido en tránsito: la autenticación usa un desafío-respuesta con una clave privada que nunca sale del dispositivo.
Los estándares que lo aportan:
- FIDO2 / WebAuthn: el estándar de navegador y plataforma para autenticación de clave pública.
- Passkeys: credenciales FIDO2, ya sea ligadas al dispositivo (llave de seguridad hardware, p. ej. YubiKey) o sincronizadas (respaldadas en un ecosistema de proveedor como Apple, Google o un gestor de contraseñas).
- PIV / tarjetas inteligentes (x.509): el enfoque clásico de empresa y administración pública.
Por qué los proxies AiTM fallan contra ella
Usuario → phish.example (proxy del atacante) → real.example
La aserción WebAuthn se firma sobre el origen que ve el navegador:
clientDataJSON.origin = "https://phish.example"
La credencial se registró para "https://real.example"
→ desajuste de origen → el autenticador/RP rechaza la aserción
No hay código que el usuario retransmita ni cookie que el proxy coseche, porque el inicio de sesión nunca tiene éxito contra el origen equivocado. Lo impone el navegador, no la persona.
Desplegarlo sin romper nada
Priorice por riesgo. Empiece por administradores, finanzas, directivos y cualquiera con acceso a los sistemas más críticos. Son las cuentas que los kits AiTM atacan primero.
Planifique la recuperación de cuenta. La recuperación es el nuevo punto débil: si una llave perdida cae de vuelta a SMS o a una llamada al soporte, ha reintroducido la vía phishable. Exija dos autenticadores registrados por usuario (p. ej. una llave de seguridad más un passkey de plataforma) y refuerce la verificación de identidad en el soporte.
Gestione parques mixtos. Los passkeys sincronizados facilitan el despliegue en dispositivos personales y móviles; las llaves ligadas al dispositivo encajan en escenarios de alta garantía y compartidos/quiosco. Muchas organizaciones usan ambos.
Secuencie la migración:
- Habilite FIDO2/passkeys junto a la MFA existente.
- Registre un segundo factor y lance campañas de alta.
- Pase los roles privilegiados a resistente al phishing obligatorio.
- Retire el SMS y la voz como factores.
- Amplíe el requisito de resistencia al phishing a toda la organización mediante acceso condicional.
Aspire a que lo resistente al phishing sea obligatorio, no solo disponible. Mientras exista un repliegue phishable, los atacantes dirigirán a los usuarios hacia él, una técnica conocida como degradación de MFA.
Cómo ayuda GottaPhish
La MFA phishable —OTP y push— da una falsa sensación de seguridad mientras deja una brecha real que los atacantes explotan activamente; tener la tecnología no la cierra. GottaPhish y su equipo de expertos le ayudan a construir el argumento de negocio y a ejecutar el despliegue: nuestras simulaciones al estilo AiTM demuestran, de forma segura y medible, cómo la MFA por OTP y push cae ante un proxy real, dando a la dirección la evidencia para financiar la MFA resistente al phishing. A partir de ahí, nuestros expertos guían su despliegue de FIDO2/passkeys de forma práctica —priorizando roles de alto riesgo, planificando el alta con doble autenticador y la recuperación, e informando de la adopción junto a sus métricas de clic y notificación— y le ayudan a interpretar los resultados para que pueda demostrar que la brecha phishable se está cerrando de verdad.