MFA resistente al phishing: por qué el SMS ya no basta

El SMS ya no basta porque su código puede leerse desde otro canal y, sobre todo, porque el usuario puede entregarlo a un sitio falso en tiempo real. Solo la autenticación vinculada criptográficamente al origen, como WebAuthn con claves de seguridad o passkeys, resiste ese intermediario.

Esta es una comparación de ingeniería, no una recomendación de marca. No nombramos productos ni tenemos acuerdos de afiliación con fabricantes de autenticadores: lo que sigue son propiedades de protocolo, verificables en las especificaciones enlazadas.

¿Por qué falla la MFA basada en códigos?

Todos los métodos que consisten en que una persona lea un secreto y lo escriba comparten el mismo fallo estructural: el secreto viaja por el usuario, y el usuario no sabe distinguir a quién se lo está dando.

El ataque canónico es el proxy inverso en tiempo real. El atacante levanta una réplica del portal legítimo que actúa de intermediario: la víctima teclea usuario, contraseña y código, el proxy los retransmite al servicio real en el mismo segundo, y captura la cookie de sesión resultante. El código de un solo uso se usa una sola vez, sí, pero la usa el atacante. Y a partir de ahí ya no necesita el segundo factor, porque tiene la sesión.

Sobre eso se apilan debilidades específicas de cada método:

• SMS: duplicado fraudulento de tarjeta SIM, portabilidad no autorizada del número y debilidades históricas de la señalización de la red telefónica. Por eso NIST SP 800-63B clasifica el uso de la red telefónica conmutada para verificación fuera de banda como autenticador restringido, y exige a quien lo mantenga ofrecer una alternativa no restringida, avisar del riesgo y tener un plan de migración.
• Código temporal de aplicación (TOTP): definido en el RFC 6238, elimina la dependencia de la red móvil, pero sigue siendo un secreto compartido transcribible. Además, la semilla inicial se copia al configurarlo, y muchas aplicaciones la sincronizan en la nube.
• Notificación push de aprobación: sustituye el tecleo por un toque, y con ello introduce el bombardeo de peticiones: el atacante, que ya tiene la contraseña, lanza decenas de solicitudes hasta que alguien acepta por cansancio o confusión. El emparejamiento de números mitiga el problema pero no lo elimina, porque el número también se puede mostrar al usuario desde la página falsa.

El propio SP 800-63B es explícito en el punto de fondo: los autenticadores de introducción manual, como los códigos de un solo uso, no se consideran resistentes a la suplantación del verificador, porque su salida no queda ligada a la sesión concreta.

¿Qué hace distinta a la autenticación vinculada al origen?

La diferencia no es "más segura": es de otra categoría.

En Web Authentication Level 2, recomendación del W3C publicada en abril de 2021, cada credencial se crea vinculada a un identificador de parte confiante y el origen queda incluido y firmado en el proceso. En castellano llano: la clave privada nunca sale del autenticador, y la firma que produce solo es válida para el dominio para el que se registró.

Las consecuencias prácticas son tres:

1. No hay secreto que entregar. No existe un código que el usuario pueda teclear en el sitio equivocado.
2. El dominio falso no obtiene firma. Si el usuario está en un dominio distinto —aunque sea uno con un carácter cambiado— el autenticador no firma para ese origen. El ataque no se detecta: sencillamente no funciona.
3. La clave privada no es exfiltrable desde el servidor, porque el servidor solo guarda la pública.

Esto es lo que la Agencia de Ciberseguridad e Infraestructura de EE. UU. denomina MFA resistente al phishing en su ficha Implementing Phishing-Resistant MFA, publicada junto con la guía sobre emparejamiento de números en octubre de 2022. Las dos familias que CISA señala como resistentes son FIDO2/WebAuthn y la infraestructura de clave pública basada en tarjeta (PIV/CAC).

La revisión NIST SP 800-63B-4, de julio de 2025, actualiza el marco de niveles de garantía de autenticación e incorpora el tratamiento de los autenticadores criptográficos modernos.

¿Cómo se comparan los cuatro métodos?

Método	Resiste proxy en tiempo real	Resiste duplicado de SIM	Resiste bombardeo de peticiones	Coste de despliegue	Dónde encaja
Código por SMS	No	No	No aplica	Muy bajo	Solo como último recurso, con plan de salida
Código temporal de aplicación	No	Sí	No aplica	Bajo	Respaldo controlado y cuentas de bajo impacto
Notificación push simple	No	Sí	No	Bajo	No recomendable como factor único de segundo nivel
Push con emparejamiento de números y contexto	Parcialmente	Sí	Mejora, no elimina	Bajo	Transición mientras se despliega WebAuthn
Passkey sincronizada (WebAuthn)	Sí	Sí	Sí	Medio	Plantilla general en dispositivo gestionado
Clave de seguridad en hardware (WebAuthn)	Sí	Sí	Sí	Medio-alto	Cuentas privilegiadas y de alto impacto

Una precisión honesta sobre la última columna: ningún control elimina el riesgo. WebAuthn cierra el vector de suplantación del sitio, y deja abiertos otros —robo de sesión ya iniciada mediante malware en el equipo, abuso de procedimientos de recuperación, o consentimiento indebido a una aplicación conectada—. La resistencia al phishing es una propiedad concreta y acotada, no una promesa general.

¿A quién se le da cada nivel?

El error de despliegue más común es intentar el todo o nada. El criterio útil es asignar por impacto de la cuenta, no por cargo.

Nivel máximo — clave de seguridad en hardware, con registro de al menos dos por persona:

• Administradores de identidad, de directorio y de la consola de nube.
• Cuentas con capacidad de emitir o aprobar pagos y de modificar datos de beneficiario. El motivo lo desarrollamos en Fraude del CEO en una compraventa: cómo cortarlo.
• Acceso a repositorios de código y a canalizaciones de despliegue.
• Buzones de dirección y de los responsables de operaciones sensibles.
• Cuentas de acceso a bases de datos con datos personales de categoría especial.

Nivel alto — passkey en dispositivo gestionado: el resto de la plantilla con acceso a sistemas internos.

Nivel de transición — push con emparejamiento de números: mientras dure el despliegue, y con fecha de fin escrita.

Nivel a extinguir — SMS: solo donde el proveedor no ofrezca alternativa, con inventario explícito de esos casos y revisión trimestral.

Dos reglas que valen más que la tabla entera:

• La cuenta de recuperación se protege igual o mejor que la principal. Una cuenta con clave de hardware cuyo restablecimiento de contraseña llega a un correo personal con SMS no está protegida con clave de hardware: está protegida con SMS.
• Registrar dos autenticadores desde el primer día. El bloqueo por pérdida del único dispositivo es la causa número uno de que una organización desactive el control entero "temporalmente".

¿Qué exige la normativa y qué exige el riesgo?

Conviene no confundir el suelo regulatorio con el nivel adecuado.

En Estados Unidos, la Safeguards Rule de la FTC obliga a las instituciones financieras no bancarias cubiertas a implantar autenticación multifactor para cualquier persona que acceda a sistemas con información de clientes. La norma exige MFA; no distingue entre métodos resistentes y no resistentes al phishing. Cumplir con SMS es posible y, a la vez, insuficiente frente al ataque real.

Esa brecha entre "cumple" y "resiste" es exactamente el terreno donde trabajamos: los controles se implantan de verdad y el estado de cada marco se declara con honestidad, como puede verse en /trust. El detalle del enfoque está en servicios: compliance y en servicios: protección.

¿Cómo se despliega sin romper la operación?

Un plan de seis pasos que funciona en organizaciones pequeñas y medianas:

1. Inventario de cuentas por impacto. Sin este paso el despliegue se ordena por comodidad y deja fuera lo importante.
2. Piloto con el equipo técnico, dos autenticadores por persona, durante dos semanas.
3. Extensión a cuentas privilegiadas con bloqueo de métodos débiles en esos perfiles, no en toda la organización.
4. Endurecimiento de la recuperación antes de tocar la plantilla general: procedimiento de restablecimiento con verificación fuera de banda y registro.
5. Plantilla general con passkeys, comunicación clara y ventana de soporte reforzado los primeros días.
6. Retirada progresiva del SMS, con lista de excepciones justificadas y fecha de revisión.

Y un control de cordura: si el portal de acceso admite todavía un método débil como alternativa para las cuentas privilegiadas, el atacante elegirá ese. La resistencia de un sistema de autenticación es la de su opción más débil habilitada, no la de la mejor.

Conviene además no confundir capas: cifrar el transporte no autentica a nadie. Es un error frecuente y lo tratamos en VPN corporativa: qué protege de verdad y qué no.

Qué hacer ahora

1. Lista las cuentas que pueden mover dinero, cambiar identidades o desplegar código. Ese es el primer lote, y suele caber en una hoja.
2. Comprueba qué métodos de recuperación siguen activos en esas cuentas. Ahí está casi siempre el eslabón débil.
3. Registra dos autenticadores por persona antes de bloquear nada.
4. Fija la fecha de retirada del SMS por escrito, con las excepciones inventariadas.
5. Prueba un intento real de proxy inverso en un entorno controlado y con autorización expresa. Ver el fallo silencioso convence más que cualquier presentación.

Si quieres que diseñemos y despleguemos el plan de autenticación, incluida la parte incómoda —recuperación, cuentas de servicio y excepciones—, escríbenos desde /contacto.