Fatiga de MFA: cuando el segundo factor cede al cansancio

La conclusión: el segundo factor no falla por tecnología, falla por cansancio de la persona

Cuando un atacante ya tiene la contraseña de un empleado, lo único que se interpone es el segundo factor. Y ese factor no suele caer porque alguien rompa un algoritmo, cae porque una persona, cansada e interrumpida, termina aprobando un acceso que no pidió. Eso es la fatiga de MFA: la autenticación multifactor (MFA), el segundo paso que se pide además de la contraseña, no se vulnera por vía técnica, se desgasta por vía humana.

La idea incómoda es que la tecnología hizo su parte. El sistema pidió la confirmación, tal como debía. El punto de quiebre está más adelante, en el momento en que una notificación número doce, a las once de la noche, recibe el toque que la hace desaparecer. No hay una máquina fallando en esa escena, hay una persona bajo presión. Por eso conviene mirar la fatiga de MFA como lo que es: una técnica de ingeniería social que usa la repetición y el cansancio como palanca, no como un defecto del software.

Qué es la fatiga de MFA y el bombardeo de notificaciones push

La fatiga de MFA es un ataque que consiste en bombardear a la persona con solicitudes de aprobación hasta que una de ellas es aceptada. También se le conoce como bombardeo de notificaciones push o, en inglés, push bombing y prompt bombing. El punto de partida siempre es el mismo: el atacante ya consiguió la contraseña, por una filtración previa, por un correo de phishing o por reutilización de claves, y ahora necesita superar el segundo factor.

Con la contraseña en la mano, el atacante intenta iniciar sesión una y otra vez. Cada intento dispara una notificación en el celular de la víctima, esa ventana que pregunta si fuiste tú quien está entrando. La apuesta es estadística y psicológica: si las solicitudes llegan sin parar, en medio de una reunión, durante la cena o de madrugada, tarde o temprano la persona aprueba, por accidente al desbloquear el teléfono o simplemente para que las notificaciones se detengan. Basta una sola aprobación. En ese instante, la protección que debía frenar al intruso lo deja pasar.

Por qué el MFA por aprobación es vulnerable a la presión y la repetición

El MFA por aprobación es vulnerable porque delega la decisión de seguridad en una persona interrumpida, y le pide un juicio de valor bajo condiciones diseñadas para agotarla. La debilidad no está en el segundo factor en sí, está en el tipo de segundo factor: uno que se resuelve con un toque, sin más contexto que la pregunta de si fuiste tú.

Ese formato tiene tres grietas que el atacante explota a la vez. La primera es la ambigüedad: la notificación no dice desde dónde ni por qué llega el intento, así que la persona decide a ciegas. La segunda es la repetición: una solicitud aislada se examina, pero la número quince ya no se lee, se despacha. La tercera es el contexto emocional: el bombardeo llega en el peor momento a propósito, cuando la prioridad de la persona es seguir con lo suyo, no auditar un inicio de sesión. Conviene recordar de dónde viene el riesgo. El marco 90-5-5 de Cisco estima que cerca del 90 por ciento de las brechas involucran un factor humano. No hablamos de gente descuidada: hablamos de personas haciendo su trabajo, que reciben una interrupción tras otra hasta que una cede. Esta es la misma raíz de toda la ingeniería social, manipular la confianza y el cansancio en lugar de vulnerar la máquina, un patrón que ya revisamos al ver cómo frenar la ingeniería social en las empresas.

MFA resistente a phishing frente a MFA por aprobación

La diferencia de fondo es simple: el MFA por aprobación le pide a la persona que decida, y el MFA resistente a phishing saca esa decisión de sus manos. Ahí está la línea que separa un segundo factor que se puede agotar de uno que no.

Un MFA por aprobación, sea un push que se acepta con un toque o un código que se teclea, depende de que la persona valide correctamente cada intento, y cualquier método que dependa de un juicio humano repetido se puede desgastar con volumen y presión. Un MFA resistente a phishing funciona distinto: ata la autenticación al dispositivo y al sitio legítimo, de modo que un intento desde otro lugar simplemente no se completa, sin importar cuántas veces se repita ni qué decida la persona en el momento. CISA recomienda de forma explícita adoptar MFA resistente a phishing como la defensa principal contra la fatiga de MFA y contra el phishing en general, y señala el estándar FIDO2 como la referencia. Para las organizaciones que todavía no pueden migrar y siguen con notificaciones push, CISA propone una medida intermedia, la verificación por coincidencia de números (number matching): en vez de un toque, la persona debe leer en la pantalla de inicio de sesión un código y escribirlo en la aplicación de autenticación. Ese paso extra rompe el aprobar por inercia, porque obliga a mirar de dónde viene el intento antes de confirmarlo.

La comparación entre ambos enfoques se lee mejor en una tabla.

Ninguna de las dos capas vuelve invencible a una empresa por sí sola, y la migración a un MFA resistente a phishing toma tiempo y presupuesto. Pero la dirección es clara: cuanto menos dependa la seguridad de una decisión humana tomada bajo presión, menos superficie le queda a la fatiga de MFA.

Cómo preparar a la persona y validar que resiste el patrón

La defensa completa combina tecnología y comportamiento: endurecer el segundo factor y, a la vez, comprobar que la persona reconoce el patrón cuando lo tiene enfrente. Lo primero reduce la superficie, lo segundo confirma que la reducción de verdad funciona con gente real, no en el papel.

Del lado técnico, la prioridad es migrar hacia un MFA resistente a phishing y, mientras eso ocurre, exigir coincidencia de números y limitar cuántas solicitudes seguidas puede disparar una cuenta. Del lado humano, la persona necesita saber que una ráfaga de aprobaciones que no solicitó no es un problema técnico del teléfono, es un ataque en curso, y que la respuesta correcta es negar y reportar, nunca aprobar para que pare. Como el ataque arranca cuando el atacante ya tiene la contraseña, detectar a tiempo las credenciales expuestas cierra parte del flanco antes de que empiece el bombardeo.

Falta la capa que casi siempre se omite: comprobar que la persona de verdad resiste el patrón, no solo que asistió a una charla sobre él. Aquí cobra sentido el concepto de retest. Explicarle a un empleado qué es la fatiga de MFA y darlo por resuelto es una ilusión cómoda: hay evidencia revisada por pares de que completar una capacitación no predice por sí solo la reducción de fallos reales. Lo que demuestra que alguien aprendió no es haber terminado el módulo, es volver a enfrentarlo semanas después, con una variante distinta del mismo tipo de presión, y ver si esta vez no cede. Validar el cambio de comportamiento en lugar de asumirlo es la idea central de la gestión de riesgo humano (Human Risk Management, HRM), y es lo que separa una defensa real de una casilla marcada.

En Fensivo abordamos este caso de uso uniendo la simulación realista del patrón con la validación posterior: una persona que enfrenta un escenario de presión sobre su segundo factor y luego lo vuelve a enfrentar, semanas después y con otra variante, demuestra con hechos que aprendió a no ceder, no que recordó una charla. Puedes ver cómo lo planteamos en nuestros casos de uso.

¿Cuánto de la seguridad de tus cuentas depende hoy de que una persona cansada, a las once de la noche, tenga el criterio de rechazar la notificación número doce en lugar de aprobarla para que pare?