La mayoría de las organizaciones que sufrieron una brecha el año pasado tenían la autenticación multifactor activada. Esa es la parte incómoda. Los atacantes no rompieron el segundo factor: lo rodearon, con técnicas que funcionan precisamente porque el MFA implantado le pide a una persona cansada que tome una decisión de seguridad en el peor momento posible.
Si su MFA es un código por SMS o una notificación de un solo toque para «¿Aprobar?», esto merece diez minutos de su atención. Esos dos métodos son hoy aquellos que los atacantes planifican rodear, no los que los detienen.
Tres ataques que vencen a «algo de MFA»
- Push-bombing (fatiga de MFA). El atacante ya tiene la contraseña, obtenida de una filtración, de un phishing o de la reutilización de credenciales. Desencadena un inicio de sesión tras otro, disparando una avalancha de avisos de aprobación al teléfono del usuario hasta que, por confusión o simplemente para que pare, alguien toca Aprobar. Un solo toque y ya están dentro. Así empezaron varias brechas de nombres muy conocidos.
- SIM swapping. El SMS nunca se diseñó como canal de seguridad. Un atacante que convence (o soborna) a un operador móvil para trasladar un número a una nueva SIM recibe todos los códigos de un solo uso que se envían a ese número. Sin malware, sin página de phishing: basta una llamada a un servicio de atención al cliente.
- Adversary-in-the-middle (AiTM). Una página de inicio de sesión falsa y convincente actúa de intermediaria con la real en tiempo real. La víctima introduce su contraseña y su código; el atacante retransmite ambos al instante y roba el token de sesión resultante. El código era válido. El MFA «funcionó». La cuenta se ha perdido igualmente.
El hilo común: cada uno de estos métodos depende de un secreto o una aprobación que puede retransmitirse, es decir, copiarse del usuario legítimo y reproducirse por el atacante. Corte esa retransmisión y los tres ataques se detienen con ella.
Lo que realmente los detiene: autenticación resistente al phishing y ligada al hardware
«Resistente al phishing» no es lenguaje de marketing: designa una propiedad concreta. Dos cosas tienen que cumplirse a la vez: la clave nunca puede salir del dispositivo del usuario, de modo que no hay nada que capturar y reutilizar; y el usuario puede leer exactamente qué está aprobando, de modo que nada se aprueba a ciegas.
- La clave reside en el hardware seguro del teléfono. Se genera allí y no puede exportarse, copiarse ni trasladarse mediante SIM swap. No hay ningún secreto compartido guardado en una base de datos ni que llegue por SMS, y eso es lo que cierra la puerta a la interceptación, al SIM swap y a la retransmisión AiTM.
- Puede leer exactamente qué está aprobando. Esta es la parte que detiene el push-bombing, y conviene ser precisos: ninguna clave ni ninguna biometría sirven de nada una vez que la solicitud llega al teléfono, porque el ataque simplemente le pide al usuario que diga que sí. La biometría solo confirma que quien toca es el dueño del teléfono, no que el inicio de sesión sea legítimo. Lo que derrota al push-bombing es que cada solicitud lleva una descripción específica y legible de exactamente qué se está aprobando: este inicio de sesión, este servidor, desde aquí, ahora. Un aviso que el usuario nunca inició es visiblemente ajeno, así que lo rechaza. La salvaguarda es una descripción lo bastante precisa como para leerla de un vistazo, no una persona cansada resistiéndose a un «¿Aprobar?» en blanco.
- La sesión no puede reproducirse. Como la firma es criptográfica y está vinculada a la solicitud, un proxy AiTM no tiene nada que valga la pena robar.
Esa es la diferencia entre un MFA que sube el listón y un MFA que el atacante ya tiene automatizado para saltárselo.
Dónde encaja Notakey
Notakey se construyó justamente en torno a esta propiedad. La clave del usuario se genera dentro del hardware seguro de su teléfono y nunca sale de él, y cada aprobación es un registro firmado y con marca de tiempo de la acción concreta, no un toque anónimo.
- Ningún secreto compartido que robar con phishing, ningún SMS que interceptar, ningún código que retransmitir.
- Frente al push-bombing, la defensa es lo que el usuario lee: cada solicitud muestra una descripción precisa de exactamente qué se está aprobando —qué sistema, qué acción, desde dónde—, de modo que un aviso que nadie inició resulta evidente a simple vista y se rechaza. No hay nada que aprobar a ciegas.
- Cubre las vías que los atacantes usan de verdad; consulte las guías prácticas sobre 2FA en una VPN con RADIUS, escritorio remoto de Windows y SSH en Linux.
Compruébelo usted mismo
La forma más rápida de notar la diferencia es aprobar una transacción al modo resistente al phishing: leer y firmar una acción concreta desde su propio teléfono, en lugar de tocar un aviso sin contexto.
Pruebe la demo en vivo para firmar una en unos dos minutos, o solicite una demostración y trazaremos sus inicios de sesión de VPN, SSO o Windows hacia un piloto en su propia infraestructura.