Autenticación resistente al phishing: alcances y límites de MFA y passkeys

La protección depende del protocolo, del destino al que se vincula la credencial y de lo que ocurre antes y después del inicio de sesión.

Qué demuestra MFA y qué deja sin resolver

La autenticación multifactor exige demostrar control de factores de categorías distintas. NIST SP 800-63B-4 admite, en el nivel AAL2, un autenticador multifactor o una combinación de factores separados. Un dispositivo criptográfico que requiere un factor local de activación puede satisfacer ese diseño; contar pantallas, pasos o solicitudes de aprobación no permite determinar por sí solo la fortaleza de una autenticación.[2]

La resistencia al phishing responde a otra pregunta: ¿puede un verificador impostor obtener secretos o respuestas válidas de autenticación y utilizarlos contra el servicio legítimo? NIST define esta propiedad sin hacerla depender de la vigilancia del usuario. Por eso, los códigos de un solo uso introducidos manualmente y los mecanismos fuera de banda no se consideran resistentes al phishing: la respuesta no queda vinculada de la manera requerida a la sesión que se está autenticando.[3]

Un código que caduca y solo puede usarse una vez puede resistir la repetición posterior y, aun así, ser retransmitido por un intermediario durante una autenticación. Confundir resistencia a la repetición con resistencia al phishing lleva a atribuir a MFA una protección que el protocolo concreto no ofrece.[3]

CISA recomienda adoptar MFA resistente al phishing. Su boletín del 31 de octubre de 2022 presenta la coincidencia de números, o number matching, como una mitigación transitoria frente a la fatiga de aprobaciones cuando todavía no es posible esa adopción. La mejora tiene valor, pero no equivale a la propiedad criptográfica que se busca.[5]

La vinculación con el servicio cambia la defensa

En una autenticación criptográfica, el usuario demuestra control de una clave mediante una operación verificable. NIST reconoce dos vías de resistencia al phishing: vincular la respuesta al canal autenticado o vincularla al nombre autenticado del verificador. WebAuthn, utilizado por implementaciones FIDO2, es un ejemplo de la segunda: la selección del secreto del autenticador depende del dominio autenticado del servicio.[3]

Esta vinculación explica la diferencia con escribir un código en una página que imita a otra. La respuesta criptográfica no funciona como un secreto que el usuario deba reconocer y entregar al destinatario correcto. En el modelo descrito por NIST, el protocolo limita su uso al verificador correspondiente. La resistencia proviene de esa relación técnica, no del aspecto visual de la página ni de que el usuario advierta una anomalía.[3]

La consecuencia práctica es exigir evidencia de la implementación. Que una interfaz anuncie «sin contraseña» no identifica automáticamente sus factores, su vinculación al verificador ni su nivel de garantía. Esos atributos deben comprobarse en el flujo completo y en la validación que realiza el servicio.[2][4]

Passkeys sincronizadas y vinculadas a un dispositivo

FIDO Alliance describe las passkeys como credenciales basadas en sus estándares y distingue entre las sincronizadas a través de un servicio y las vinculadas a un único dispositivo. Pueden utilizarse desde equipos, teléfonos o llaves de seguridad, según la implementación. Esta distinción importa porque la disponibilidad de una credencial en varios dispositivos incorpora requisitos sobre su almacenamiento, transferencia y recuperación.[6]

El apéndice B de NIST SP 800-63B-4 permite que los autenticadores sincronizables respalden AAL2 si cumplen sus requisitos y los aplicables al nivel. Exige, entre otros controles, almacenamiento cifrado de las claves exportadas, operaciones con la clave privada en el dispositivo local y acceso al entorno de sincronización protegido por MFA equivalente a AAL2. La sincronización no elimina por sí misma la resistencia al phishing.[4]

AAL3 requiere una clave privada no exportable, además de los demás controles correspondientes. Por esa razón, NIST excluye de AAL3 los autenticadores sincronizables. Tampoco basta con que una passkey esté vinculada a un dispositivo para afirmar que alcanza AAL3: deben verificarse las restantes exigencias sobre hardware, criptografía, factores e intención de autenticación.[2]

Otro detalle decisivo es la verificación local del usuario. NIST distingue la interacción con el autenticador, indicada por User Present, de la verificación del usuario, indicada por User Verified. En las implementaciones que describe, el verificador debe inspeccionar esta última señal para determinar si puede tratar al autenticador como multifactor. Tocar un dispositivo no prueba, por sí solo, que se haya verificado un segundo factor.[4]

Alcance normativo: la edición final de SP 800-63B-4 se publicó en julio de 2025. Sus requisitos se formulan para el contexto de identidad digital federal estadounidense. Aquí se utiliza como referencia técnica; no se presenta como una obligación general para todas las organizaciones ni como sustituto de la regulación aplicable en Colombia.[1]

El inicio de sesión no agota la seguridad de la cuenta

Recuperación y registro de nuevos autenticadores

La pérdida de un dispositivo no debe convertirse en una pérdida definitiva de acceso, pero la recuperación necesita su propio diseño de seguridad. NIST la trata como un proceso distinto de la autenticación y exige notificar al titular los eventos de recuperación. También establece requisitos para vincular nuevos autenticadores y notificaciones independientes cuando se agrega uno. El análisis de riesgo debe abarcar esos recorridos, no solo el método preferido de entrada.[7]

La misma atención se aplica a las passkeys sincronizadas. NIST identifica como riesgos el acceso no autorizado al entorno de sincronización, sus procesos de recuperación y el uso de claves compartidas. Como criterio de implementación, conviene revisar qué permite agregar un dispositivo, recuperar la cuenta del proveedor y retirar una credencial comprometida.[4]

Sesiones y dispositivos

Después de autenticarse, muchas aplicaciones mantienen una sesión mediante un secreto, por ejemplo una cookie. NIST aclara que las cookies no son autenticadores y analiza separadamente el robo de secretos de sesión, su protección y sus tiempos de validez. Por tanto, una passkey resistente al phishing no demuestra que una sesión posterior esté protegida frente a todas las formas de secuestro.[8]

La protección del dispositivo también permanece dentro del problema. NIST exige controles para preservar claves y factores de activación y contempla la intención de autenticación como defensa frente al uso sin conocimiento del titular, incluido el que podría intentar software malicioso. La conclusión técnica es acotada: reducir una vía de suplantación no convierte al equipo, al navegador o a la aplicación en invulnerables.[3]

Privacidad y biometría sin afirmaciones absolutas

En la autenticación FIDO descrita por la Alianza, la biometría se procesa localmente y no se envía al servidor remoto. Sirve para la verificación del usuario que habilita el uso del autenticador; no es la clave privada que se transmite al sitio. Esta característica no debe generalizarse a cualquier sistema que anuncie reconocimiento facial o de huella.[6]

NIST advierte que las características biométricas no son secretos y contempla riesgos de privacidad, especialmente cuando se almacenan para verificación centralizada. Prefiere la comparación local, exige tratar los datos biométricos como información personal sensible y dispone que exista una alternativa no biométrica dentro de su marco.[3]

La evaluación de privacidad debe incluir también los registros de acceso, los atributos y la información recogida para gestionar autenticadores. NIST exige evaluar la retención y aplicar controles adecuados; además, limita el condicionamiento del servicio a consentimientos para usos adicionales. Una implementación responsable define qué datos conserva, para qué finalidad, durante cuánto tiempo y quién puede consultarlos.[2][9]

Criterios verificables para una implementación

A partir de estas fuentes, una evaluación de adopción puede organizarse alrededor de cinco verificaciones. Son criterios de análisis derivados de los documentos citados, no una certificación de conformidad:

1. Identificar la propiedad requerida. Documentar el nivel de garantía, los factores y el mecanismo de resistencia al phishing de cada acceso. En AAL2, NIST exige ofrecer al menos una opción resistente al phishing; para el acceso del personal, contratistas y socios a sistemas federales, establece su uso obligatorio. Es necesario conservar esa diferencia de alcance.[2]
2. Comprobar la respuesta del autenticador. Revisar la vinculación al verificador y, cuando corresponda, las señales de presencia, verificación del usuario y posibilidad de sincronización. La etiqueta comercial no reemplaza esta validación.[3][4]
3. Revisar las rutas alternativas. Analizar recuperación, incorporación de dispositivos, alta de autenticadores y mecanismos de respaldo. Su seguridad y sus notificaciones forman parte del ciclo de vida de la cuenta.[7]
4. Evaluar la sesión posterior. Verificar protección de los secretos de sesión, caducidad, cierre y reautenticación conforme al riesgo y al nivel seleccionado.[8]
5. Documentar privacidad y funcionamiento real. Determinar qué datos se recogen, las condiciones de sincronización y las opciones disponibles cuando una persona no puede usar biometría o pierde su autenticador.[3][4][9]

Conclusiones

MFA describe una combinación de factores; resistencia al phishing describe una propiedad del protocolo. Las passkeys implementadas con la vinculación adecuada al verificador permiten avanzar sobre una debilidad concreta de los secretos que una persona puede entregar a un impostor. El nivel de garantía depende, además, de cómo se activa y protege el autenticador y de si sus claves pueden exportarse.[2][3][4]

La decisión rigurosa exige evaluar la autenticación junto con la recuperación, la sincronización, las sesiones y la privacidad. Sobre esa base puede demostrarse qué amenazas se reducen y qué controles siguen siendo necesarios, sin prometer una seguridad absoluta ni descartar una mejora porque no resuelva todos los riesgos.