MFA: factores de autenticación, TOTP/HOTP y el patrón step-up
MFA (Multi-Factor Authentication) es la práctica de combinar dos o más factores independientes para autenticar a un usuario. Resuelve el problema estructural de la contraseña única, que lleva décadas demostrando ser insuficiente frente a phishing, reutilización y brechas masivas. En el ecosistema actual, MFA es el denominador mínimo exigible, y step-up authentication es el patrón que evita imponerlo de forma indiscriminada.
Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas. MFA lleva tanto tiempo recomendándose que casi se da por hecho, pero la realidad sigue mostrando que no todas las aplicaciones lo exigen, no todos los factores son equivalentes, y no todas las integraciones lo invocan cuando deberían. En este artículo se revisa qué es exactamente un factor, cómo funcionan TOTP y HOTP, por qué SMS y push fatiguen han dejado de considerarse factores fuertes, qué dice NIST sobre niveles de autenticación, y cómo el patrón step-up se ha convertido en la forma sensata de pedir MFA sin saturar al usuario.
Por qué la contraseña sola dejó de ser suficiente
El problema con la contraseña no es teórico. Los volcados masivos de credenciales (desde LinkedIn 2012 hasta los incidentes de años recientes) han puesto en circulación miles de millones de pares usuario-contraseña reutilizables por tercios. El phishing industrial captura credenciales en tiempo real. El credential stuffing automatiza el reintento en miles de servicios. Y la recomendación clásica de “contraseña fuerte y rotación frecuente” se demostró contraproducente: genera contraseñas memorizables por patrones y rotaciones superficiales. NIST lo reconoció explícitamente al retirar la obligación de rotación periódica y al desaconsejar pistas y preguntas de seguridad.
La conclusión operativa es que un solo factor, sobre todo si es conocimiento, no es una barrera fiable. Añadir un segundo factor independiente eleva el coste del atacante en órdenes de magnitud, no porque cada factor individual sea perfecto, sino porque comprometer ambos a la vez exige capacidades muy distintas.
Qué cuenta como factor
La taxonomía clásica reconoce tres familias. Conocimiento (algo que el usuario sabe): contraseña, PIN, respuesta a pregunta secreta. Posesión (algo que el usuario tiene): teléfono con app autenticadora, security key, smart card, token hardware. Inherencia (algo que el usuario es): huella, rostro, iris, patrones biométricos conductuales. Se añaden a veces localización y tiempo, aunque formalmente estos se tratan como señales de contexto más que como factores, y alimentan la autenticación adaptativa.
Dos factores solo cuentan como MFA si son independientes. Contraseña más pregunta de seguridad son dos factores de conocimiento: no es MFA. Push a la misma app donde el usuario tiene su sesión activa puede degradar la independencia si el dispositivo está comprometido. La independencia real se consigue cuando el compromiso de un factor no implica el compromiso automático del otro.
HOTP y TOTP: el OTP estandarizado
HOTP (HMAC-based One-Time Password), definido en RFC 4226 (diciembre 2005), generaliza la idea del token hardware RSA SecurID a un esquema abierto basado en HMAC-SHA-1 con un contador que se incrementa en cada uso. El servidor y el cliente comparten una clave secreta, el cliente calcula un HMAC sobre el contador, trunca el resultado a seis u ocho dígitos y lo muestra. El servidor acepta la ventana de contadores próxima al suyo.
TOTP (Time-based One-Time Password), definido en RFC 6238 (mayo 2011), sustituye el contador por una ventana temporal, típicamente 30 segundos. El mismo algoritmo, mismo HMAC, pero el input es el timestamp dividido por el periodo. Esto elimina el problema de desincronización por uso (HOTP puede desincronizarse si el usuario genera códigos sin usarlos) y es lo que implementan prácticamente todas las apps autenticadoras: Google Authenticator, Microsoft Authenticator, Aegis, 1Password, Bitwarden, Authy.
TOTP es compatible con WebAuthn y passkeys, pero es claramente inferior en resistencia a phishing. Un atacante que monta un proxy intermedio puede capturar el código TOTP del usuario y reenviarlo al servicio real dentro de la ventana de validez. Funciona contra credential stuffing y contra phishing básico, no contra adversary-in-the-middle bien construido. Es por eso que los frameworks regulatorios modernos empujan hacia factores ligados criptográficamente al origen, como los descritos en FIDO2, WebAuthn y Passkeys.
SMS, llamadas y por qué pierden peso
El SMS como segundo factor tuvo un papel enorme en la adopción temprana de MFA por su cobertura universal. Hoy se considera un factor débil. El SIM swapping permite a un atacante, con ingeniería social sobre el operador, portar el número a una SIM que controla y recibir los códigos. Los ataques a SS7 permiten interceptar SMS sin tocar el dispositivo. En jurisdicciones con regulación de portabilidad laxa la barrera es baja. NIST SP 800-63B degradó los canales telefónicos a “restricted”: se pueden usar, pero con advertencias y plan de migración a alternativas.
Lo mismo aplica, por vectores distintos, a los push a dispositivo con aprobación binaria. El ataque típico, conocido como MFA fatigue o prompt bombing, consiste en lanzar notificaciones hasta que el usuario aprueba por accidente o por cansancio. Se ha visto en incidentes públicos de alto perfil. La mitigación es number matching (el usuario debe introducir un número que aparece en la pantalla de login), limitación de prompts por unidad de tiempo, y contexto visible (ubicación, aplicación) en el prompt.
Si hoy estás desplegando MFA por primera vez, SMS puede ser un primer paso funcional pero no el destino. Planifica desde el inicio la migración a TOTP, y desde TOTP a WebAuthn/Passkeys para las poblaciones y las acciones donde importa.
Niveles AAL de NIST SP 800-63B
NIST SP 800-63B, actualizado en sus revisiones sucesivas, define tres niveles de assurance de autenticación. AAL1 permite single-factor con contraseña robusta; es el mínimo donde casi nada crítico debería vivir. AAL2 exige dos factores, con resistencia a replay y secretos en canales protegidos; cubre la mayoría de escenarios empresariales. AAL3 exige un factor criptográfico hardware, resistente a phishing y a suplantación del verificador; corresponde a autenticadores como security keys FIDO2 en modo hardware-bound. Este marco es útil no solo para organismos federales estadounidenses: aparece referenciado por aseguradoras, auditorías y contratos corporativos a nivel global.
Step-up authentication
Exigir MFA en cada acción saturaría al usuario y acabaría siendo bypassado por tickets internos. La alternativa es step-up: el usuario se autentica al inicio con una garantía determinada, y cuando intenta una acción de mayor sensibilidad (transferir fondos, cambiar una clave API, ver datos personales, firmar un contrato), la aplicación solicita un factor adicional o la renovación de uno existente.
El trigger puede ser por sensibilidad de la acción (transacciones por encima de un umbral), por riesgo evaluado (login desde ubicación inusual, dispositivo no reconocido, cambio de IP a mitad de sesión), por tiempo transcurrido desde la última reautenticación (reauth obligatoria cada cierta ventana), o por política regulatoria (PSD2 SCA en pagos).
En el mundo OIDC, step-up se articula mediante tres piezas del estándar. El parámetro acr_values en la petición de autorización indica al IdP qué clase de autenticación se requiere (por ejemplo, un valor que mapee a AAL2 o AAL3). El claim amr en el ID Token devuelve qué métodos se usaron realmente (pwd, otp, mfa, hwk, sc, fpt, entre otros definidos en RFC 8176). El parámetro max_age obliga a que la autenticación se haya producido dentro de una ventana reciente, provocando reauth si ha pasado más tiempo. Con esas tres herramientas, una aplicación puede pedir al IdP que eleve la garantía cuando toca, y el IdP decide si basta con refrescar sesión o si debe pedir factor adicional.
Existe también el draft de OAuth 2.0 Step-Up Authentication Challenge (RFC 9470, septiembre 2023), que formaliza cómo un API puede responder con un challenge indicando qué acr y max_age necesita, y cómo el cliente debe repetir la autorización pidiendo esos valores. Con este mecanismo el API deja de tener que anticipar la autenticación necesaria: rechaza con información suficiente para que el cliente repita el flujo al nivel correcto.
Adaptive y risk-based
Los IdPs maduros añaden una capa más: evalúan señales (dispositivo conocido vía cookie o fingerprint, geolocalización, velocidad imposible entre sesiones, reputación de IP, horario habitual del usuario, integridad del dispositivo vía MDM) y deciden dinámicamente si el login actual exige un factor adicional. Esto se combina con step-up: un usuario que entra desde su dispositivo habitual a una acción poco sensible pasa sin fricción; el mismo usuario entrando desde un dispositivo nuevo o desde una red anómala recibe una petición de MFA aunque la acción sea rutinaria.
La autenticación adaptativa solo es útil si las señales son fiables y si los usuarios pueden recuperar el acceso cuando algo falla (dispositivo robado, cambio de país legítimo). Un diseño sin path de recuperación claro convierte la adaptividad en bloqueo aleatorio.
Cuándo no imponer MFA (y cuándo sí, sin excepción)
En aplicaciones B2C con acciones de bajísima sensibilidad (consulta de catálogo público, suscripción a newsletter), forzar MFA en cada login añade fricción sin beneficio proporcional. Se puede ofrecer como opción, y activarlo solo al primer acceso a zonas sensibles. En aplicaciones internas con Zero Trust completo donde cada request ya está autorizada por múltiples señales, MFA en el acceso inicial puede bastar si hay reauth periódica.
La regla inversa es: cualquier acceso con privilegios administrativos, cualquier acceso a datos regulados, cualquier acceso a infraestructura de producción, cualquier proceso de cambio de credenciales, exige MFA sin negociación. Los incidentes repetidos en cuentas de soporte, de on-call y de service desk son un recordatorio constante de que ahí es donde más duele el atajo.
Encaje con el resto de la arquitectura
MFA no es una pieza aislada: es una capacidad del IdP, expresada hacia las aplicaciones mediante OIDC (acr, amr, max_age), ligada a políticas de acceso en Keycloak, Okta y los IdP modernos, y culminada en factores modernos como FIDO2, WebAuthn y Passkeys cuando se busca resistencia a phishing. Dentro de una arquitectura Zero Trust, MFA es una de las evidencias continuas que permiten que cada decisión de acceso se tome con información suficiente, y no solo sobre la base de lo que ocurrió al inicio de la sesión.
Artículos relacionados en esta serie
Referencias
- RFC 4226 (diciembre 2005). HOTP: An HMAC-Based One-Time Password Algorithm.
- RFC 6238 (mayo 2011). TOTP: Time-Based One-Time Password Algorithm.
- RFC 8176 (junio 2017). Authentication Method Reference Values.
- RFC 9470 (septiembre 2023). OAuth 2.0 Step Up Authentication Challenge Protocol.
- NIST (2017, revisiones sucesivas). SP 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management.