Autenticación multifactor, explicada.

Una contraseña es un punto único de fallo disfrazado. Puede sufrir phishing, reutilizarse en una docena de sitios filtrados, adivinarse a partir de un patrón predecible o teclearse directamente en una página de inicio de sesión falsa pixel-perfect. La autenticación multifactor (MFA) existe para eliminar ese punto único de fallo exigiendo una segunda prueba de identidad, independiente, antes de conceder el acceso –de modo que una contraseña robada por sí sola ya no basta para entrar. Pero no toda la MFA es igual. Algunos métodos frenan en seco a casi cualquier atacante remoto; otros se pueden sortear con un atacante paciente y un usuario molesto. Este artículo recorre cómo funciona en realidad cada método principal de MFA, por qué los códigos SMS son los más débiles del grupo, y cómo un patrón de ataque concreto y bien documentado conocido como fatiga MFA o prompt bombing apunta a la única parte del sistema que la criptografía no puede blindar: la paciencia humana.

Qué significa en realidad «multifactor»

Los factores de autenticación se dividen en tres categorías independientes, y la autenticación multifactor genuina combina pruebas de al menos dos categorías distintas –no dos pruebas de la misma categoría. Dos contraseñas no son MFA. Una contraseña más una pregunta de seguridad es apenas mejor, porque ambas viven en la misma categoría y ambas pueden sufrir phishing, adivinarse o filtrarse en la misma brecha de datos.

En la práctica, la MFA casi siempre combina una contraseña (algo que sabes) con un segundo factor de la categoría «algo que tienes». Ese segundo factor es donde vive la verdadera diferencia de seguridad entre las distintas implementaciones –un mensaje de texto y una llave criptográfica hardware satisfacen ambos, sobre el papel, «algo que tienes», pero resisten a los atacantes en grados enormemente distintos, que es precisamente el tema de este artículo.

Contraseñas de un solo uso basadas en tiempo (TOTP): el estándar de las apps de autenticación

Las apps de autenticación como Google Authenticator, Microsoft Authenticator, Authy y 1Password implementan todas el mismo estándar abierto: TOTP, definido en el RFC 6238. Durante el registro, el servicio y tu app acuerdan un secreto compartido –normalmente entregado como un código QR que codifica una cadena en base32. A partir de ese momento, ambas partes pueden calcular de forma independiente el mismo código de 6 dígitos sin volver a hablar entre sí jamás: toman el secreto compartido, lo combinan con el tiempo Unix actual dividido en pasos fijos (casi siempre 30 segundos) y lo procesan mediante un algoritmo de contraseña de un solo uso basado en HMAC (RFC 4226, el antecesor no basado en tiempo sobre el que se construye TOTP). Como tanto la app como el servidor se limitan a hacer cálculos contra un reloj, no hace falta ningún viaje de ida y vuelta por red –por eso una app de autenticación sigue generando códigos válidos en modo avión y sin cobertura.

Puedes ver ese mismo cálculo exacto en la línea de comandos, usando el mismo secreto de demostración que aparece en la mayoría de los tutoriales y librerías de TOTP:

$ oathtool --totp -b JBSWY3DPEHPK3PXP
123456

Ese único comando hace exactamente lo mismo que una app de autenticación hace localmente cada 30 segundos: decodificar el secreto en base32, derivar un contador de tiempo y producir un código. La fortaleza de TOTP es que el servicio nunca te transmite el código para que te llegue –no hay ningún mensaje SMS ni notificación push que interceptar en tránsito. Su exposición principal está en los dos extremos: una página de phishing que pide el código en tiempo real y lo reenvía al sitio real dentro de la ventana de 30 segundos, o malware capaz de extraer el secreto de registro de un dispositivo o de una copia de seguridad sin cifrar.

Códigos SMS de un solo uso: cómodos, y el eslabón más débil

Los códigos SMS siguen muy extendidos porque no necesitan ninguna app y funcionan en cualquier teléfono capaz de recibir un mensaje de texto. Esa comodidad tiene el coste de depender de la seguridad de la propia red telefónica –una superficie de ataque que no tiene nada que ver con la cuenta protegida y todo que ver con infraestructura que el titular de la cuenta no controla.

• SIM swap. Un atacante manipula mediante ingeniería social, o en algunos casos documentados soborna, a un empleado de un operador móvil para que traslade el número de la víctima a una SIM que él controla. A partir de ese momento, todos los códigos SMS destinados a la víctima –incluidos los de restablecimiento de contraseña– llegan al dispositivo del atacante en su lugar.
• Debilidades de señalización SS7. Los mensajes de texto SMS se enrutan entre operadores mediante SS7, un protocolo de señalización de telecomunicaciones de décadas de antigüedad con debilidades de diseño conocidas. Investigadores de seguridad han documentado formas de interceptar tráfico SMS a través de SS7 sin llegar a tocar la SIM física de la víctima, lo que significa que una defensa contra el SIM swap por sí sola no cierra del todo esta brecha.
• Reenvío en tiempo real. Como un código SMS no es más que una cadena que el usuario teclea en un formulario de inicio de sesión, una página de phishing puede capturarlo en el momento en que llega y reenviarlo al servicio real antes de que caduque –la misma debilidad que comparte TOTP, sin siquiera la pequeña protección de no transmitir nunca el código por una red pública.

Las directrices de identidad digital del NIST (SP 800-63B) señalaron los códigos de un solo uso entregados por SMS como un autenticador «fuera de banda» más débil y empujaron a las organizaciones hacia alternativas más sólidas allá donde fuera práctico, aunque sin llegar a prohibir el SMS por completo. La conclusión práctica es sencilla: trata el SMS como el recurso de última instancia, no como el predeterminado, siempre que un servicio ofrezca algo más sólido.

MFA por notificación push: rápida, hasta que se abusa de ella

La MFA push –Duo Push, Okta Verify, las solicitudes de aprobar/denegar de Microsoft Authenticator– envía una notificación a un dispositivo ya registrado y vinculado a tu cuenta. Pulsas «Aprobar» (a menudo después de comprobar una ubicación o un nombre de app mostrados como contexto) y ya estás dentro, sin ningún código que teclear. Es más rápida que TOTP y, como el dispositivo registrado tiene que tener físicamente la app instalada y vinculada, sí exige posesión, no solo el conocimiento de un código.

Esa misma comodidad –un solo toque concede el acceso– es exactamente la superficie que un atacante decidido aprendió a explotar, lo que nos lleva al ataque que este artículo existe para explicar bien.

Ataques de fatiga MFA y prompt bombing

Un ataque de fatiga MFA (también llamado prompt bombing) es una técnica bien documentada y real que no intenta romper ninguna criptografía en absoluto –apunta a la paciencia humana. El montaje exige que el atacante ya tenga en su poder un nombre de usuario y una contraseña válidos, obtenidos mediante phishing, una contraseña reutilizada de una filtración sin relación o credenciales robadas por malware infostealer. Armado con esas credenciales funcionales, el atacante intenta iniciar sesión repetidamente, y cada intento dispara una nueva solicitud de aprobación push al teléfono del usuario legítimo –a veces decenas seguidas, a veces programadas de madrugada, cuando un usuario medio dormido tiene más probabilidades de pulsar sin pensar.

La apuesta del atacante es simple: tarde o temprano el objetivo aprueba una de las solicitudes, ya sea por confusión sobre lo que está pasando, por la costumbre de pulsar «Aprobar» todo el día, o por pura molestia ante unas notificaciones que no cesan. Algunas variantes combinan el aluvión con una llamada o un mensaje de alguien que se hace pasar por soporte técnico o personal de helpdesk, indicando al objetivo que «simplemente lo apruebe» para resolver un supuesto problema del sistema –incorporando la ingeniería social directamente al ataque técnico.

Este patrón es lo bastante conocido en la comunidad de seguridad como para que los fabricantes ya integren defensas específicas contra él directamente en la MFA push:

• Coincidencia de números (number matching). En lugar de un simple botón Aprobar/Denegar, la pantalla de inicio de sesión muestra un número corto que el usuario debe teclear en la app de autenticación. Un usuario que en realidad no estaba iniciando sesión no tiene nada que teclear ni ningún motivo para abrir siquiera la app, lo que cierra casi por completo el modo de fallo de «pulsar para que pare».
• Límite de frecuencia y detección de anomalías. Poner un tope a cuántas solicitudes push puede disparar una sola cuenta en una ventana corta de tiempo, y marcar ráfagas de solicitudes denegadas o ignoradas como una señal que merece investigarse, convierte el propio patrón de ataque en una oportunidad de detección.
• Solicitudes ricas en contexto. Mostrar el dispositivo solicitante, la ubicación aproximada y el nombre de la aplicación le da a un usuario atento información real para notar que algo va mal –aunque esto solo ayuda si el usuario está prestando atención, que es precisamente lo que los ataques de fatiga están diseñados para explotar.
• Pasarse a factores resistentes al phishing. Para las cuentas de mayor valor, la solución más duradera es abandonar por completo la push de aceptar/denegar, a favor de un factor que no se pueda aprobar por error en absoluto –lo cual se trata a continuación.

Llaves de seguridad hardware y FIDO2/WebAuthn: la opción resistente al phishing

Una llave de seguridad hardware –la YubiKey es el ejemplo más conocido– se conecta por USB, NFC o Bluetooth e implementa el estándar FIDO2/WebAuthn. Durante el registro, la llave genera un par único de claves pública/privada limitado al sitio web concreto en el que te estás registrando; la clave privada nunca sale del dispositivo, y el servidor solo llega a almacenar la mitad pública.

Al iniciar sesión, el navegador le entrega a la llave un desafío criptográfico procedente del servidor. La llave lo firma y devuelve la firma –pero, de forma crucial, todo el intercambio está ligado al origen (el dominio) real del sitio web con el que está hablando el navegador, algo que se impone a nivel de protocolo y que ningún usuario puede saltarse por mucha ingeniería social que sufra. Si estás en un clon de phishing convincente alojado en un dominio distinto, la comprobación de la llave falla automáticamente: no es que un usuario cuidadoso pueda fijarse en la URL falsa, es que la propia criptografía se niega a producir una respuesta válida para el origen equivocado. Ese vínculo con el origen es precisamente lo que les falta a los códigos SMS, a los códigos TOTP y a las aprobaciones push –a un usuario se le puede engañar para que entregue cualquiera de ellos en un sitio falso, o para que apruebe una solicitud fraudulenta, porque nada en esos flujos comprueba hacia dónde va realmente la aprobación.

Las passkeys extienden la misma idea: son credenciales WebAuthn que se sincronizan entre tus dispositivos a través del gestor de contraseñas de una plataforma (iCloud Keychain, el Gestor de contraseñas de Google) en lugar de vivir en una sola pieza de hardware, heredando la misma propiedad de vínculo con el origen que las hace resistentes al phishing. La contrapartida específica de las llaves hardware es el coste y la necesidad de llevar encima un dispositivo físico –perder tu única llave sin una copia de seguridad registrada puede dejarte fuera de una cuenta por completo, por lo que registrar al menos dos llaves es el consejo habitual.

Comparando los métodos

El «No» de TOTP y de push no es una crítica a las matemáticas que hay detrás –es que ninguno de los dos métodos comprueba criptográficamente hacia dónde va la aprobación. Un proxy de phishing en tiempo real situado entre una víctima y la página de inicio de sesión real puede capturar un código TOTP en el instante en que se teclea y reenviarlo al sitio genuino antes de que se cierre la ventana de 30 segundos, o simplemente disparar él mismo la solicitud push real y esperar a que el usuario fatigado o confundido la apruebe. Solo el vínculo con el origen de WebAuthn cierra esa brecha de forma estructural, en lugar de depender de que el usuario detecte el engaño.

Elegir y combinar la MFA en la práctica

No todas las cuentas necesitan el mismo nivel de protección, pero unos pocos principios se mantienen de forma constante:

• Protege primero las cuentas que arrastran a las demás. Tu correo principal y tu gestor de contraseñas están aguas arriba de casi todo lo demás –quien los controle puede restablecer contraseñas en todos los demás sitios. Pon en ellos una llave hardware o una passkey antes que en nada más.
• TOTP es una opción predeterminada sólida y gratuita. Para la mayoría de las cuentas del día a día, una app de autenticación TOTP supone una gran mejora de seguridad frente al SMS sin coste alguno, y es lo que la mayoría de los servicios admiten de serie.
• Deja el SMS como recurso de reserva, no como principal. Donde un servicio ofrezca TOTP, push con coincidencia de números o una llave hardware, usa una de esas opciones y reserva el SMS para las cuentas que de verdad no ofrezcan nada más sólido.
• Registra copias de seguridad antes de necesitarlas. Una segunda llave hardware, códigos de recuperación impresos y guardados sin conexión, o una entrada de autenticación de respaldo evitan que perder un teléfono o una llave se convierta en un bloqueo total.
• En las organizaciones, activa la coincidencia de números en todos los sitios donde se despliegue la MFA push, y trata una ráfaga de solicitudes push denegadas o ignoradas en una sola cuenta como una señal de detección que merece una revisión inmediata, no ruido de fondo.

La conclusión

MFA no significa «añade un mensaje de texto y llámalo seguro». La categoría y el diseño del segundo factor determinan lo resistente que es en realidad a los ataques remotos y de ingeniería social: el SMS se intercepta mediante debilidades de la propia red telefónica, los códigos TOTP y las simples aprobaciones push todavía pueden sufrir phishing o reenviarse en tiempo real, y solo las llaves de seguridad hardware y las passkeys construidas sobre FIDO2/WebAuthn se niegan criptográficamente a autenticar en cualquier sitio que no sea el genuino. Añade MFA en todo lo que puedas –pero donde más se juegue, prefiere el factor que un atacante no pueda simplemente engañar, presionar o esperar a que tú mismo le entregues.

Preguntas frecuentes