Implementaciones MFA específicas: cómo funcionan por dentro

El móvil en el taxi

Sara López se deja el móvil en un taxi un jueves por la noche. Ahí tenía sus passkeys, su app de autenticación con una docena de códigos TOTP y la SIM a la que su banco le manda los códigos. El viernes por la mañana llama al servicio de ayuda desde el portátil y hace la pregunta que todo diseño de MFA acaba teniendo que responder: “¿Cómo vuelvo a entrar en mis cuentas?”. La respuesta depende de decisiones que alguien tomó meses antes, muchas veces sin pensar en este momento. Si el camino de vuelta es más débil que el camino de entrada, quien encontró el móvil, o cualquiera capaz de hacerse pasar por Sara al teléfono con el servicio de ayuda, irá por ahí.

En el artículo anterior repasamos las cinco categorías de factores y mencionamos de pasada varias implementaciones. Ahora abrimos el capó. Cada implementación tiene su propia mecánica: un protocolo, un flujo, unas debilidades concretas, decisiones de diseño que acaban en código real. Si vas a construir la autenticación de una app o a auditar la de otro, este es el nivel de detalle que necesitas. Habrá referencias a RFC, fórmulas, pseudocódigo y diagramas de secuencia a nivel de protocolo. Al terminar deberías poder explicar cómo se calcula un código TOTP, dibujar las ceremonias de registro y autenticación de WebAuthn, decir cuándo son aceptables los códigos por SMS y cuándo no, y diseñar alternativas sensatas para alguien como Sara.

Esto es un mapa, no un manual de implementación. Si vas a construir autenticación para producción, lee también los RFC que se citan por el camino y la OWASP Authentication Cheat Sheet.

TOTP y HOTP: el código que cambia cada 30 segundos

Los algoritmos de contraseña de un solo uso son el caballo de batalla del MFA empresarial desde mediados de los 2000. Son sencillos, abiertos y funcionan sin conexión.

HOTP, el predecesor

HOTP (HMAC-based One-Time Password, RFC 4226) genera códigos a partir de una semilla compartida y un contador que avanza cada vez que se genera un código:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C))
 
donde:
  K = clave secreta (semilla compartida)
  C = contador de 8 bytes (aumenta con cada código)

Servidor y cliente llevan el mismo contador. Cuando el usuario presenta un código, el servidor lo calcula con su propio contador y, si coinciden, lo acepta y avanza el contador. El problema es que si los contadores se desacompasan, por ejemplo porque el usuario generó un código y no lo usó, todo se rompe. Por eso casi nadie usa ya HOTP a secas.

TOTP, el estándar actual

TOTP (Time-based One-Time Password, RFC 6238) sustituye el contador por el tiempo dividido en ventanas de 30 segundos:

T = floor((hora_unix_actual - T0) / X)
 
TOTP(K) = HOTP(K, T)
 
donde:
  T0 = normalmente 0 (época Unix)
  X  = normalmente 30 segundos

Servidor y cliente comparten un reloj UTC y la misma semilla, así que cada 30 segundos producen el mismo código. Cuando el usuario lo escribe, el servidor calcula el suyo y los compara.

sequenceDiagram
  accTitle: Ceremonia de alta de TOTP
  accDescr: El usuario activa TOTP; el servidor genera un secreto de 160 bits y lo devuelve como un código QR otpauth; la app de autenticación lo escanea y guarda el secreto en local; el usuario introduce un código de prueba y el servidor lo verifica antes de dar el TOTP por registrado.
  actor U as Usuario
  participant App as App de autenticación
  participant Srv as Servidor
  U->>Srv: Activa TOTP en la cuenta
  Srv->>Srv: Genera el secreto K (160 bits)
  Srv->>U: Devuelve un QR con otpauth://totp/...?secret=K
  U->>App: Escanea el QR (Google Auth, Authy)
  App->>App: Guarda K en local
  U->>Srv: Introduce un código de prueba
  Srv->>Srv: Comprueba que coincide
  Srv->>U: TOTP registrado

La URI otpauth:// sigue el formato que definió Google Authenticator, que aceptan casi todas las apps de autenticación.

Los relojes se desvían, y si el del usuario va 15 segundos por detrás, su código falla en el servidor. La solución habitual es un margen de tolerancia, normalmente una ventana a cada lado, lo que da unos 90 segundos efectivos:

def validate_totp(K, code_received, current_time):
    for offset in [-1, 0, 1]:
        T = (current_time / 30) + offset
        expected = HOTP(K, T)
        if expected == code_received:
            return True
    return False

Demasiada tolerancia debilita la seguridad; demasiado poca perjudica la usabilidad.

Las debilidades de TOTP son conocidas. El phishing en tiempo real lo derrota: una web falsa pide el código y el atacante lo reutiliza en la web real en segundos. Si la app de autenticación queda comprometida, por ejemplo con malware en el móvil, el atacante puede extraer la semilla y generar códigos indefinidamente, y por eso las semillas no deberían poder exportarse con facilidad. Y las copias de seguridad en la nube de las apps de autenticación trasladan el riesgo a esa cuenta: si cae, caen con ella los códigos de todos los servicios. Para Sara, sin embargo, una copia de seguridad es justo lo que le facilitaría el viernes, y eso muestra la tensión que siempre acompaña a la recuperación.

Códigos por SMS: cómodos e indefendibles para lo valioso

El flujo por SMS es el más sencillo de todos. Inicias sesión con usuario y contraseña, el servidor genera un código de seis dígitos y se lo pasa a una pasarela de SMS, la pasarela lo entrega en tu número registrado y tú lo escribes en la app, que comprueba que coincide y que no ha caducado. Una vida típica es de cinco a diez minutos.

Sus debilidades son serias. En un SIM swapping, el atacante usa ingeniería social, sobornos o documentos falsos para que la operadora pase tu número a su SIM, y eso lleva minutos; así se hicieron con la cuenta del CEO de Twitter en 2019. El protocolo SS7 que usan las operadoras para enrutar los mensajes tiene fallos conocidos que permiten interceptarlos, demostrados en la práctica. El phishing en tiempo real funciona igual que contra TOTP. Los empleados de la operadora pueden leer los mensajes. Y cuando un número se libera y se reasigna, el nuevo titular puede recibir mensajes dirigidos al anterior. En el caso de Sara, quien encontró su móvil en el taxi recibe ahora los códigos de su banco, al menos hasta que ella bloquee la SIM.

NIST SP 800-63B desaconseja los códigos por SMS para AAL2, pero todavía tienen su sitio. Algo de MFA es mejor que nada, así que un código por SMS es mejor que una contraseña sola. Llega a usuarios sin smartphone moderno. Y puede servir como canal alternativo secundario. Lo que no debería ser es el factor principal de nada que implique dinero, datos personales sensibles o acceso de administración. La normativa bancaria de varios países ya prohíbe el SMS como único factor para operaciones de alto valor.

Códigos por email: tan seguros como el buzón

Los códigos por correo funcionan como los de SMS, pero por email. Su seguridad depende por completo de la de la cuenta de correo. Si esa cuenta solo está protegida con una contraseña, el “MFA con código por email” es un único factor disfrazado: un atacante con acceso al buzón inicia el inicio de sesión, recibe el código y termina. Y si el correo es además el canal de “he olvidado mi contraseña”, el buzón basta por sí solo para hacerse con todos los servicios registrados con él. Los códigos por email son razonables en apps de poco valor donde la fricción de TOTP no se justifica, como alternativa cuando se pierde el dispositivo del TOTP, con comprobaciones adicionales, y para confirmar una dirección en el alta, no para el inicio de sesión recurrente.

Notificaciones push

sequenceDiagram
  accTitle: Flujo de autenticación por notificación push
  accDescr: Después de que el usuario inicie sesión con email y contraseña, el IdP pide a un servicio de push que avise a la app móvil registrada; el usuario aprueba con un toque; la app móvil confirma con una firma del dispositivo; el IdP devuelve un token y empieza la sesión.
  actor U as Usuario
  participant App as App web
  participant IdP as IdP
  participant PushSvc as Servicio de push
  participant Phone as App móvil
  U->>App: Inicia sesión con email + contraseña
  App->>IdP: Autentica el primer factor
  IdP->>PushSvc: Pide un push al dispositivo registrado
  PushSvc->>Phone: Notificación: "¿Eres tú?"
  U->>Phone: Aprueba (un toque)
  Phone->>IdP: Confirma con la firma del dispositivo
  IdP->>App: Token con claims
  App->>U: Sesión iniciada

La experiencia es excelente: un toque y estás dentro. También trajo un riesgo nuevo, la fatiga de MFA o bombardeo de push. Un atacante que ya tiene la contraseña manda notificación tras notificación hasta que la víctima, cansada, distraída o medio dormida, aprueba una. Así entró un atacante de Lapsus$ en Uber en 2022.

Las plataformas modernas responden con varias medidas. La coincidencia de números sustituye el simple botón de aprobar por un número, por ejemplo 47, que el usuario tiene que escribir o elegir en la app donde está iniciando sesión, lo que impide aprobar por reflejo. Mostrar la ubicación y el contexto en la notificación (“Inicio de sesión desde Tokio. ¿Eres tú?”) permite a un usuario que está en Madrid detectar la incoherencia y rechazarla. Los límites de frecuencia bloquean la cuenta y lanzan una alerta si, por ejemplo, salen más de tres notificaciones en cinco minutos. Y exigir Face ID o la huella dentro de la app de autenticación hace que un toque a secas no baste. Microsoft Authenticator, Duo y Okta Verify activan la coincidencia de números por defecto desde 2023.

FIDO2 y WebAuthn: el estándar resistente al phishing

FIDO2 es la pareja de estándares, WebAuthn y CTAP, que sustituye los secretos compartidos por criptografía asimétrica anclada al dispositivo del usuario. Es la autenticación para consumidores más fuerte que existe hoy. Lo que la distingue de todo lo anterior es que el dominio de la web forma parte de lo que se firma. La llave no firma “soy Sara”; firma “soy Sara en banco.com”. Si te llevan a banko.com, con una letra cambiada, la firma nombra el dominio falso y el servidor real la rechaza.

WebAuthn tiene dos ceremonias: el registro, la primera vez, y la autenticación, en cada inicio de sesión posterior.

sequenceDiagram
  accTitle: Ceremonia de registro de WebAuthn (atestación)
  accDescr: El servidor envía un desafío y unas opciones; el navegador llama a navigator.credentials.create; el autenticador pide un gesto, genera un par de claves y guarda la privada en local, y devuelve la pública con una atestación firmada; el navegador reenvía la clave pública y el servidor la guarda asociada al usuario.
  participant U as Usuario
  participant Browser as Navegador
  participant Auth as Autenticador (YubiKey, TPM, Secure Enclave)
  participant Srv as Servidor
  Srv->>Browser: Desafío + opciones
  Browser->>Auth: navigator.credentials.create()
  Auth->>U: Pide un gesto (toque, biometría)
  Auth->>Auth: Genera el par de claves
  Auth->>Auth: Guarda la clave privada en local
  Auth->>Browser: Clave pública + atestación firmada
  Browser->>Srv: Envía la clave pública
  Srv->>Srv: Guarda la clave pública asociada al usuario

El servidor guarda la clave pública; la privada nunca sale del autenticador. En el siguiente inicio de sesión se ejecuta la ceremonia de autenticación.

sequenceDiagram
  accTitle: Ceremonia de autenticación de WebAuthn (aserción)
  accDescr: El navegador pide un desafío; el servidor devuelve un desafío aleatorio y el origen; el navegador llama a navigator.credentials.get incluyendo el origen; el autenticador pide un gesto y firma el desafío más el origen con la clave privada; el navegador envía la firma y el servidor la verifica con la clave pública guardada antes de iniciar la sesión.
  participant U as Usuario
  participant Browser as Navegador
  participant Auth as Autenticador
  participant Srv as Servidor
  U->>Browser: Empieza el inicio de sesión
  Browser->>Srv: Pide un desafío
  Srv->>Browser: Desafío aleatorio + origen
  Browser->>Auth: navigator.credentials.get(), con el origen
  Auth->>U: Pide un gesto
  Auth->>Auth: Firma desafío + origen con la clave privada
  Auth->>Browser: Firma
  Browser->>Srv: Envía la firma
  Srv->>Srv: Verifica la firma con la clave pública
  Srv->>Browser: Sesión iniciada

El paso que importa es la firma sobre el desafío y el origen. Si el origen de la web falsa es banko.com, el navegador se lo pasa al autenticador y la firma resultante contiene banko.com. El servidor real comprueba la firma con la clave pública guardada, ve que el origen firmado no es su dominio y la rechaza. Así que, aunque engañen al usuario para que apruebe en una web falsa, el atacante no puede usar esa firma en la real. Ningún código de un solo uso ni ninguna notificación push pueden decir lo mismo.

Hay dos tipos de autenticadores. Los itinerantes son dispositivos aparte que se conectan por USB, NFC o Bluetooth, como una YubiKey o una Google Titan. Los de plataforma vienen integrados en el dispositivo: Touch ID, Face ID, Windows Hello, la biometría de Android.

Passkeys: WebAuthn sincronizado entre dispositivos

Las passkeys son la evolución de WebAuthn pensada para el consumidor, y arreglan dos problemas de la versión clásica: perder el dispositivo suponía perder la credencial, y cada dispositivo necesitaba su propio registro, lo que hacía penoso cambiar de móvil.

Las passkeys son credenciales descubribles. El autenticador guarda la clave privada y también un identificador del usuario, así que al iniciar sesión el usuario ni siquiera escribe su email; el navegador le ofrece directamente “iniciar sesión con la passkey de Sara López”. Y la clave privada se sincroniza mediante iCloud Keychain, el Gestor de contraseñas de Google o Windows Hello entre los dispositivos de la misma persona, de modo que una passkey creada en un iPhone funciona en el Mac y en el iPad sin registrar cada uno.

flowchart LR
  accTitle: Passkeys sincronizadas entre los dispositivos de un usuario
  accDescr: Una passkey creada en un iPhone se sincroniza mediante un iCloud Keychain cifrado de extremo a extremo con el Mac y el iPad del mismo usuario, y puede usarse en un equipo Windows mediante un código QR entre dispositivos.
  iPhone[iPhone<br/>passkey original] --> iCloud[(iCloud Keychain<br/>cifrado E2E)]
  iCloud --> Mac[Mac<br/>passkey sincronizada]
  iCloud --> iPad[iPad<br/>passkey sincronizada]
  iCloud -.alternativa.-> Windows[Windows con QR<br/>entre dispositivos]

Esto es lo que le salva el viernes a Sara. Sus passkeys no estaban solo en el móvil del taxi; también estaban en su portátil, sincronizadas a través de su cuenta en la nube. Si hubiera perdido todos los dispositivos, recuperar la cuenta en la nube le devolvería las passkeys, y en un equipo prestado podría escanear un código QR con otro de sus dispositivos para usar una passkey de forma temporal.

Las passkeys también tienen límites. Cambiar de ecosistema es incómodo, porque las passkeys de iCloud no se exportan fácilmente a Google. No todas las apps las admiten todavía, aunque eso cambia deprisa. Y algunos entornos B2B regulados exigen FIDO2 con un autenticador de hardware y no uno sincronizado, porque una cuenta en la nube comprometida expondría todas las passkeys sincronizadas. Para consumidores, las passkeys son la mejor opción en 2026. Para administradores y cuentas empresariales críticas, plantéate una llave de hardware aparte cuya clave privada nunca salga del chip físico.

Enlaces mágicos

Un enlace mágico es una URL de un solo uso que se envía al email del usuario y que completa el inicio de sesión al pulsarla. Lo usan Slack, Notion, Medium y muchos productos modernos.

sequenceDiagram
  accTitle: Flujo de inicio de sesión con enlace mágico
  accDescr: El usuario introduce su email; el servidor genera un token aleatorio asociado al email con una vida limitada y envía por correo un enlace que lo contiene; el usuario pulsa el enlace, que navega a un endpoint de autenticación; el servidor valida el token, lo marca como usado para que no se pueda reutilizar e inicia la sesión.
  actor U as Usuario
  participant App as App web
  participant Srv as Servidor
  participant Mail as Correo
  U->>App: Introduce su email
  App->>Srv: Pide un enlace mágico
  Srv->>Srv: Genera un token aleatorio
  Srv->>Srv: Lo asocia al email + vida limitada
  Srv->>Mail: Envía el enlace con el token
  U->>Mail: Pulsa el enlace
  Mail->>App: Navega a /auth?token=...
  App->>Srv: Valida el token
  Srv->>Srv: Lo marca como usado (no reutilizable)
  Srv->>App: Sesión iniciada

Unos cuantos patrones mantienen seguros los enlaces mágicos. El token es de un solo uso, así que una vez consumido no vuelve a funcionar. Su vida es corta, normalmente de 10 a 15 minutos. Es largo, idealmente de 256 bits, aleatorio e impredecible. Y, de forma opcional, si el enlace se abre desde un país o un dispositivo distinto del que lo pidió, la app pide una confirmación adicional. Las debilidades son las mismas que las de los códigos por email: quien controla el buzón controla la cuenta, una regla de reenvío automático descuidada puede mandar el enlace a otro buzón y un correo de phishing puede imitar el de verdad con el enlace del atacante (la verificación del remitente, como BIMI, ayuda aquí). Un patrón habitual en apps modernas es el enlace mágico como primer factor más push o TOTP como segundo, combinando la sencillez del enlace con un factor independiente.

CAPTCHA: antibots, no autenticación

El CAPTCHA no es un factor de autenticación. No demuestra que seas tú; sugiere que eres humano, o al menos que te comportas como tal. Se confunden porque los CAPTCHA aparecen en los formularios de acceso junto a la contraseña. Lo que hace un CAPTCHA es encarecer el abuso automatizado: el credential stuffing, en el que un atacante prueba millones de credenciales filtradas; los bots que registran diez mil cuentas falsas en una hora; y la fuerza bruta cuando la limitación de intentos se queda corta.

Hoy hay varios tipos. reCAPTCHA v2 es la casilla “No soy un robot”, que analiza el movimiento del ratón y el comportamiento. reCAPTCHA v3 es invisible y devuelve una puntuación entre 0,0 y 1,0 sin que el usuario haga nada. hCaptcha es una alternativa que paga a las webs por los datos de entrenamiento que recoge. Cloudflare Turnstile es un control antibots centrado en la privacidad, sin el rastreo de Google. Y los CAPTCHA de prueba de trabajo, como Anubis, hacen que el navegador resuelva un acertijo criptográfico. El reCAPTCHA de Google recoge muchos datos de comportamiento, lo que molesta a muchos operadores, y Turnstile y hCaptcha se presentan como las opciones respetuosas con la privacidad.

Nunca confíes en un CAPTCHA como única defensa contra la fuerza bruta. La defensa principal sigue siendo la limitación de intentos, el bloqueo progresivo y la vigilancia de patrones, y un CAPTCHA nunca es un factor de autenticación.

Alternativas y recuperación

Por buena que sea la autenticación principal, la gente pierde dispositivos, olvida contraseñas y cambia de número, como le pasó a Sara. Necesitas planes de recuperación, y son el punto más débil de muchos sistemas, porque cualquier camino que deja volver a entrar al usuario es también un camino que puede probar un atacante.

El principio detrás de todos es sencillo: el camino de recuperación no puede ser más débil que la autenticación principal. Si entras con passkey y biometría pero te recuperas con un código por SMS, la seguridad efectiva de todo el sistema es la del SMS, porque un atacante siempre elegirá la puerta más débil. Si el servicio de ayuda de Sara le restableciera el MFA tras una llamada en la que da su fecha de nacimiento y su número de empleada, todo lo demás de su configuración sería decoración.

Cómo elegir: tres escenarios

La pregunta que más sale en la práctica es “¿qué factor implemento en mi caso?”. No hay una única respuesta; depende del riesgo, del público y de la madurez del equipo. Tres casos típicos muestran el razonamiento.

Una app de banca móvil para consumidores en Centroamérica atiende a clientes de todas las edades, muchos con móviles de gama media, bajo una normativa local que exige MFA de verdad y con la expectativa de una experiencia fluida. Un buen diseño usa la passkey como factor principal allí donde el dispositivo la admite, más TOTP y biometría en el dispositivo, con códigos por SMS como alternativa solo para clientes con móviles antiguos, y autenticación escalonada con PIN de operaciones para las operaciones de más de 200 dólares. Las passkeys eliminan el phishing, el ataque dominante en banca; TOTP cubre los casos en que las passkeys aún no son posibles; y el SMS solo aparece cuando no hay alternativa.

Una app interna de RR. HH. para 200 empleados, mantenida por un equipo pequeño con poco presupuesto, debería apoyarse en el inicio de sesión único con el proveedor de identidad corporativo, como Microsoft Entra ID o Google Workspace, que ya aplica MFA. La app no debería implementar su propio MFA. Reutilizar la inversión que ya ha hecho la empresa es lo eficiente, y meter un MFA a medida en cada app interna duplica trabajo y multiplica la superficie de ataque.

Un panel de administración para operaciones críticas, por ejemplo la administración de clústeres de Kubernetes para ocho ingenieros de plataforma con acceso a producción, es el caso en que una credencial comprometida es una catástrofe. Aquí una llave de hardware FIDO2 por ingeniero es obligatoria, y las acciones destructivas, como borrar un clúster o cambiar políticas de IAM, exigen autenticación escalonada más la aprobación de un segundo ingeniero. Es donde el coste y la fricción de una llave de hardware compensan, y las passkeys sincronizadas no bastan, porque quieres que la clave privada no salga nunca de un chip físico.

Hay un patrón que se repite en los proyectos: los equipos tienden a pasarse de diseño con los usuarios finales, añadiendo demasiada fricción, y a quedarse cortos con los administradores, dando por hecho que saben lo que hacen. Debería ser al revés. Los usuarios finales toleran menos fricción y los administradores necesitan más controles. Cuando diseñes, trata los dos públicos por separado.

Qué factor para qué trabajo

Resumen

Las implementaciones de MFA no son intercambiables; cada una resuelve un problema concreto y tiene su propio modelo de amenazas. TOTP y HOTP son sencillos y funcionan sin conexión, pero caen ante el phishing en tiempo real. Los códigos por SMS son cómodos pero están expuestos al SIM swap y a SS7, así que no sirven para nada valioso. Los códigos por email son tan seguros como el buzón y funcionan como alternativa acotada. El push es agradable de usar pero necesita coincidencia de números para resistir el bombardeo de MFA. FIDO2 y WebAuthn son el estándar resistente al phishing para cuentas críticas, y las passkeys son su forma pensada para el consumidor, ideal para la identidad de clientes moderna. Los enlaces mágicos son sencillos y dependen del correo. Los CAPTCHA combaten bots y no son autenticación. Y por encima de todos hay una regla: el camino de recuperación nunca puede ser más débil que la autenticación principal.

Tres preguntas para ponerte a prueba

1. Diseña el flujo de recuperación para Sara, que perdió el iPhone donde tenía sus passkeys y sus códigos TOTP. ¿Qué pasos incluirías, qué comprobaciones harías y por qué cada una?
2. Tu CTO dice: “Despleguemos passkeys y quitemos las contraseñas en una semana”. ¿Qué tres advertencias le harías sobre la transición y la compatibilidad?
3. Una app permite iniciar sesión con un enlace mágico y sin segundo factor para cualquier acción. Diseña tres autenticaciones escalonadas que recomendarías añadir y el tipo de operación que cubriría cada una.