Dos pasos no describen la propiedad que importa
Una pantalla pide contraseña y después un one-time password (OTP) de seis dígitos. Otra pide contraseña y muestra una notificación con el botón «Aprobar». Una tercera solicita una passkey y desbloquea una clave con la biometría local del teléfono. Las tres experiencias pueden llamarse multi-factor authentication (MFA), pero no ofrecen la misma resistencia a replay, phishing, compromiso del verificador, duplicación del autenticador ni recuperación abusiva.
La pregunta profesional no es cuántas pantallas atravesó una persona. Hay que identificar qué factores demostró, qué autenticador los representa, qué output produjo, a qué sesión y verificador quedó vinculado, qué secreto conserva cada parte y qué caminos alternativos permiten entrar. Un sistema con un mecanismo principal fuerte y una recuperación débil hereda la frontera de seguridad de la recuperación. Un sistema que autentica bien pero autoriza mal sigue permitiendo operaciones indebidas.
NIST SP 800-63B-4 define la resistencia al phishing como una propiedad del protocolo: debe impedir que un verificador impostor obtenga secretos o outputs válidos sin depender de que la persona detecte el engaño. La entrada manual de un OTP no satisface esa propiedad porque un impostor puede capturarlo y retransmitirlo mientras sigue vigente. En cambio, un protocolo criptográfico puede vincular su output al canal o al nombre autenticado del verificador. NIST SP 800-63B-4, §3.2.5
Este capítulo construye ese modelo desde los factores hasta WebAuthn, y desde la ceremonia normal hasta binding, pérdida, recuperación y revocación. «Passkey», «Fast Identity Online 2 (FIDO2)» o «MFA» no se usarán como sellos de seguridad: cada claim conservará configuración, ceremonia y límites.
Caso conductor: una aprobación de tesorería
Northstar permite que analistas consulten facturas y que tesorería apruebe transferencias. Lara inicia sesión con contraseña y un código TOTP (Time-Based One-Time Password). El equipo propone migrar a WebAuthn, pero conserva cuatro alternativas: push para equipos antiguos, códigos de recuperación, restablecimiento por soporte y una sesión ya abierta en el móvil. Durante una prueba autorizada, una réplica del portal captura contraseña y TOTP y los retransmite al sitio real. En otro escenario, una sucesión de notificaciones hace que una persona apruebe una solicitud que no inició. En un tercero, el atacante no rompe WebAuthn: persuade al soporte para registrar un autenticador nuevo.
Los tres escenarios fallan en fronteras distintas:
- TOTP limita reutilización temporal, pero el output puede retransmitirse durante su ventana.
- Un simple «aprobar/denegar» puede expresar posesión del dispositivo sin vincular de forma suficiente la aprobación a la transacción que la persona cree autorizar.
- Una ceremonia WebAuthn correcta no protege un proceso de recuperación que crea una credencial equivalente con assurance menor.
La aprobación de una transferencia añade otra distinción. Autenticar a Lara establece evidencia sobre control de autenticadores vinculados a su cuenta. No decide si Lara puede aprobar esa cuenta bancaria, ese importe o una operación ya modificada. La autorización debe evaluar principal, acción, recurso y estado; si la operación requiere confirmación transaccional, el diseño debe vincular los datos relevantes a esa decisión en lugar de inferirlos de un login anterior.
Factor, autenticador y output son objetos diferentes
Un factor de autenticación pertenece a una de tres clases habituales: algo que se sabe, algo que se tiene o algo que se es. Dos contraseñas siguen siendo dos instancias de «algo que se sabe», no dos factores distintos. Un autenticador es el medio que permite demostrar control de uno o más factores. El protocolo fija los mensajes, el estado, el contexto y las reglas con las que se genera, transporta, verifica y consume esa prueba. Un authenticator output es el valor producido para una ceremonia: un OTP, una firma u otra respuesta verificable. La credencial es información vinculada a la cuenta que permite verificar ese control; una sesión conserva continuidad después de autenticar.
La biometría merece precisión. En el modelo de NIST, una característica biométrica no se acepta por sí sola como autenticador remoto. Puede actuar como factor de activación local de un autenticador físico: el sensor verifica localmente y habilita el uso de una clave. El servidor puede recibir evidencia de user verification, no la huella o el rostro. Así, una passkey desbloqueada con huella puede constituir un autenticador criptográfico multifactor: posesión de la clave más activación biométrica. El resultado depende de que se exija y se verifique el flag apropiado; una interfaz biométrica no basta para inferirlo. NIST SP 800-63B-4, §§2.2–2.3 y §3.2.3
Tampoco toda combinación es independiente. Si contraseña y semilla TOTP están en el mismo gestor sincronizado y la misma recuperación de cuenta restablece ambos, el protocolo puede seguir presentando dos clases de factor durante el login, pero existe una causa común de compromiso. El análisis profesional separa cumplimiento de la ceremonia, resistencia del autenticador y dependencias del ciclo de vida.
Desliza horizontalmente para leer el diagrama a tamaño completo.
HOTP: un contador compartido convertido en código
HMAC-Based One-Time Password (HOTP) usa el mecanismo Hash-based Message Authentication Code (HMAC) con una clave simétrica compartida K y un contador móvil C. De forma abreviada:
HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10^Digits
RFC 4226 define el contador como un valor de ocho bytes, aplica truncamiento dinámico al HMAC y obtiene un valor decimal de al menos seis dígitos. El verificador conoce la misma clave y calcula candidatos. RFC 4226, §§5.1–5.4 El código no contiene el contador; por ello, si el autenticador avanzó varias veces sin que el servidor viera esos códigos, el verificador puede buscar dentro de una ventana de resincronización.
La ventana introduce una relación cuantificable. Para un código de d dígitos, una aproximación simple a la probabilidad de acertar en un intento contra una única posición es 1 / 10^d. Si el verificador acepta s posiciones de contador y concede v intentos independientes antes de limitar, una cota aproximada —cuando s·v es pequeño frente al espacio— es s·v / 10^d. No es una garantía criptográfica completa, pero muestra por qué ampliar la ventana sin throttling empeora el margen. RFC 4226 recomienda throttling y una ventana de resincronización acotada; exige que cualquier delay o lockout cubra también sesiones paralelas. La política de aceptación única procede de NIST: un output OTP válido se acepta una sola vez mientras conserva su vigencia. RFC 4226, §§7.3–7.4 y Appendix A.4.3; NIST SP 800-63B-4, §3.1.4.2 OTP de factor único y §3.1.5.2 OTP multifactor
El secreto K es más importante que el código visible. Como autenticador y verificador comparten material equivalente, una filtración de la base de semillas puede permitir calcular outputs. Las semillas requieren confidencialidad, control de acceso, separación operacional y un proceso seguro de provisión. Hashearlas como contraseñas no permite la verificación ordinaria, porque el servidor necesita reproducir el cálculo; se requieren controles de claves adecuados al sistema.
HOTP resiste replay sólo cuando el verificador mantiene correctamente el contador y consume cada output. No queda ligado al nombre del verificador. Un sitio impostor puede solicitar un código fresco y retransmitirlo inmediatamente al sitio real antes de que la víctima lo use allí.
TOTP: el reloj reemplaza al contador de evento
Time-Based One-Time Password (TOTP) deriva el contador de tiempo:
T = floor((UnixTime - T0) / X)
TOTP = HOTP(K, T)
X es el time-step; RFC 6238 recomienda 30 segundos como valor predeterminado y exige que autenticador y verificador conozcan el mismo paso y compartan una noción de tiempo Unix. RFC 6238, §§4.1–4.2 y §5.2 El verificador suele aceptar una pequeña ventana para compensar deriva, latencia y tiempo de entrada. Cada paso adicional aceptado incrementa los candidatos válidos y debe combinarse con límites de intentos.
El reloj evita almacenar un contador de evento sincronizado, pero no elimina estado. El verificador debe impedir que el mismo OTP se acepte más de una vez durante su período válido. Para un OTP de factor único (SF-OTP), NIST exige rate limiting cuando el output tiene menos de 64 bits y lo recomienda también en los demás casos; para un OTP multifactor (MF-OTP), el verificador debe aplicarlo conforme a los requisitos de esa clase. NIST SP 800-63B-4: §3.1.4.2 SF-OTP y §3.1.5.2 MF-OTP. Debe además administrar deriva, cambio de dispositivo, reemplazo e invalidación de la semilla anterior.
Un TOTP de seis dígitos que cambia cada 30 segundos no es «imposible de interceptar». Reduce la ventana de reutilización y, con aceptación única, dificulta replay posterior. No impide un adversary-in-the-middle en tiempo real. La aplicación que llena automáticamente el código puede mejorar experiencia y reducir errores, pero no crea por sí sola verifier name binding.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Push y out-of-band: participación no equivale a contexto
La autenticación out-of-band (OOB) usa un canal secundario respecto del canal principal. En SP 800-63B-4, el flujo aceptable requiere transferir un secreto entre canales; el antiguo patrón que mostraba valores y pedía una aprobación o comparación simple dejó de considerarse aceptable porque favorece aprobaciones sin una comparación efectiva. NIST SP 800-63B-4, §3.1.3
Una notificación push es un mecanismo de entrega, no un factor adicional por sí misma. Puede despertar un autenticador OOB que establece un canal autenticado con el verificador. Si la pantalla sólo pregunta «¿Aprobar?», un atacante que ya conoce la contraseña puede iniciar solicitudes repetidas. La persona puede aprobar por confusión o para detenerlas: authentication fatigue. NIST recomienda limitar la tasa o el total de notificaciones desde la última autenticación exitosa y exige una transferencia de secreto para asociar la aprobación con la transacción. NIST SP 800-63B-4, §§3.1.3.1–3.1.3.2
Mostrar ubicación, navegador o nombre de servicio aporta contexto, pero esos datos pueden ser aproximados, compartidos o manipulables según la fuente. Number matching puede elevar el esfuerzo y reducir aprobaciones accidentales; sigue requiriendo evaluar qué valor se transfiere, quién lo generó y si un impostor puede retransmitirlo. NIST no considera phishing-resistant ni OOB ni OTP: incluso si OOB transfiere el secreto mediante QR u otro mecanismo, esa transferencia sólo asocia las dos partes del flujo y no liga criptográficamente el output al nombre o canal autenticado del verificador. La entrada manual agrava el problema, pero no es la única razón de la clasificación.
La respuesta operativa no debe culpar a la persona. Se limita la emisión, se permite reportar una solicitud no iniciada, se invalida el flujo al primer uso, se correlacionan intentos y se ofrece un autenticador resistente al phishing. La alerta útil distingue solicitud enviada, notificación entregada, autenticador activado, secreto transferido, decisión del verificador y sesión creada.
Challenge-response: frescura antes que identidad del sitio
En un protocolo challenge-response, el verificador genera un challenge impredecible y de un solo uso. El autenticador calcula una respuesta con una clave; el verificador comprueba la relación y consume el challenge. Una grabación anterior no sirve frente a un challenge nuevo. Esta es resistencia a replay, no necesariamente resistencia al phishing.
Si el output cubre sólo el challenge, un verificador impostor puede obtener una respuesta para un challenge elegido por el verificador real y retransmitirla. Para resistir ese relay, la respuesta debe quedar vinculada de forma criptográfica al canal autenticado o al identificador autenticado del verificador. SP 800-63B-4 reconoce channel binding y verifier name binding. En el segundo, el output queda ligado a un nombre de verificador autenticado; un dominio impostor no puede reutilizar una credencial cuyo alcance corresponde al dominio legítimo. NIST SP 800-63B-4, §3.2.5.1–3.2.5.2
La propiedad supone un cliente y un autenticador conformes, validación correcta del nombre/origin y una implementación del relying party (RP) que ejecute todas las comprobaciones. No protege contra código malicioso que actúa después de una autenticación legítima, una sesión robada, una autorización incorrecta o la aprobación de datos de negocio distintos a los mostrados.
Desliza horizontalmente para leer el diagrama a tamaño completo.
WebAuthn: una clave pública con alcance de relying party
Web Authentication (WebAuthn) Level 3 es una Recomendación del World Wide Web Consortium (W3C) del 25 de agosto de 2026. Define una interfaz de programación de aplicaciones (API) para crear y usar credenciales de clave pública con alcance de un WebAuthn Relying Party. Un passkey es un nombre de producto/ecosistema para una credencial WebAuthn descubrible en usos habituales; el término no determina por sí solo si la clave es sincronizable, ligada al dispositivo, multifactor, attestada o aceptable para un Authentication Assurance Level (AAL) concreto.
Registro
Durante registro, el RP entrega al navegador un challenge fresco, datos del RP y de la cuenta, algoritmos aceptados, preferencias del autenticador y política de attestation. El cliente valida que el RP ID sea válido para el origin que solicita la operación. El autenticador, con consentimiento de la persona, crea una clave para ese RP ID y devuelve un objeto de attestation con la clave pública y authenticator data. El RP debe verificar, entre otras cosas, challenge, origin, RP ID hash, flags, algoritmo y attestation según su política antes de almacenar la credencial. WebAuthn Level 3, §7.1
La clave privada no se envía al RP durante la ceremonia. El RP almacena el identificador de credencial, la clave pública y metadatos necesarios. La protección real de la privada depende del autenticador: puede estar en hardware, en almacenamiento de plataforma o ser exportable hacia un sync fabric bajo controles del ecosistema.
Autenticación
Para autenticar, el RP emite un challenge nuevo. El navegador obtiene una assertion de una credencial elegible. La firma cubre authenticatorData concatenado con el hash de clientDataJSON; este último contiene el type, challenge y origin. authenticatorData incluye rpIdHash, flags y el campo de cuatro bytes signCount. Su valor puede ser cero o no significativo cuando el autenticador no mantiene un contador; el campo forma parte de la estructura, pero no siempre aporta una señal monotónica útil. El RP debe seguir el algoritmo de verificación: comprobar challenge, origin y tipo; verificar que rpIdHash corresponde al RP ID esperado; aplicar la política de user presence (UP) y user verification (UV); comprobar la firma con la clave pública registrada; y procesar backup state y contador con sus límites. WebAuthn Level 3, §§5.8.1, 6.1 y 7.2
El RP ID y el origin no son intercambiables. El origin incluye esquema, host y puerto; el RP ID es un identificador de dominio sujeto a reglas precisas y queda representado por rpIdHash en authenticator data. El cliente valida su relación y el RP verifica ambos contextos. Un RP que omite origin, acepta challenges reutilizados o interpreta flags sin política pierde propiedades aunque la firma sea matemáticamente válida.
UP indica que ocurrió una prueba de presencia; no prueba identidad individual. UV indica que el autenticador realizó user verification, por ejemplo con PIN o biometría local. UV no revela al RP qué método se usó ni convierte automáticamente cada implementación en AAL2/AAL3. La política debe solicitar el nivel apropiado y rechazar respuestas que no lo cumplan.
La resistencia al phishing surge del alcance de la credencial al RP ID, de la validación del origin y de la firma sobre el contexto, no de que la pantalla muestre una huella. Una página en northstar-login.example no puede solicitar válidamente una assertion de la credencial vinculada a northstar.example como si fuera ese RP. Sin embargo, una vulnerabilidad o takeover dentro de un origin autorizado, una extensión maliciosa o un robo de sesión posterior pertenecen a otros escenarios.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Attestation responde una pregunta limitada
La attestation permite que el RP reciba evidencia sobre la procedencia o propiedades del autenticador durante el registro, según el formato y la cadena de confianza. Puede sostener políticas enterprise —por ejemplo, permitir sólo clases administradas—, pero no demuestra que la persona correcta controle la cuenta, que el endpoint esté libre de malware, que la clave no pueda compartirse ni que una autenticación futura autorice una operación.
WebAuthn admite varias modalidades, incluida none; navegadores y autenticadores pueden reducir información de attestation para proteger la privacidad. Incluso con attestation válida, el RP debe decidir qué trust anchors acepta, cómo trata certificados revocados y qué metadatos mantiene. La ceremonia de registro define la obtención y evaluación de esos anchors en WebAuthn Level 3, §7.1, pasos 22–24. La propia especificación advierte que attestation no elimina ataques a la ceremonia: si el atacante controla el contexto que vincula una credencial a una cuenta, puede registrar su propio autenticador perfectamente genuino. WebAuthn Level 3, §§6.5 y 13.4.4–13.4.5
Exigir attestation sin necesidad también puede aumentar la correlación, la exclusión de dispositivos y la presión hacia fallback más débil. Para servicios públicos, NIST señala que su disponibilidad limitada no debe bloquear autenticadores sincronizables y que hacerlo puede desviar a usuarios hacia opciones vulnerables al phishing. La política debe justificar qué claim necesita, qué evidencia lo sustenta y qué alternativa conserva el assurance. NIST SP 800-63B-4, Appendix B, Implementation Requirements
Sincronizable y ligado al dispositivo no significan fuerte y débil
WebAuthn Level 3 distingue backup eligibility (BE), propiedad permanente que indica si una credencial puede respaldarse, y backup state (BS), estado cambiante que indica si actualmente se encuentra respaldada. Una credencial elegible se denomina multi-device; una no elegible, single-device. WebAuthn Level 3, §§4 y 6.1.3
Una credencial sincronizable mejora disponibilidad y puede reducir recuperaciones manuales peligrosas. A cambio, amplía la frontera al sync fabric, su cuenta, cifrado, dispositivos autorizados y proceso de recuperación. NIST permite autenticadores sincronizables para AAL2 sujetos a requisitos adicionales: claves cifradas, operaciones privadas locales, acceso al fabric con MFA equivalente a AAL2 y controles de ciclo de vida. No son aptos para AAL3, que exige una clave privada no exportable. NIST SP 800-63B-4, Appendix B.2–B.4
Una credencial ligada a dispositivo reduce movilidad de la clave, pero su pérdida puede forzar recuperación; tampoco prueba hardware resistente a extracción sin evidencia adicional. Por ello, la selección no se resume como «device-bound seguro, synced inseguro». Se modelan amenazas, AAL requerido, población, administración, disponibilidad, attestation, recuperación y capacidad de revocación.
Los contadores de firma tampoco son un detector universal de clonación. WebAuthn permite autenticadores que no mantienen un contador significativo; credenciales multi-device complican una lectura monotónica global. Una disminución o repetición puede ser señal de riesgo, pero el RP debe tratarla según la especificación y su contexto, no rechazar de forma automática toda autenticación legítima.
Desliza horizontalmente para leer el diagrama a tamaño completo.
AAL expresa assurance de autenticación, no privilegio
Los Authentication Assurance Levels (AAL) de NIST describen confianza en que el claimant controla autenticadores vinculados a la cuenta. AAL1 admite autenticación de uno o varios factores y los verificadores deberían ofrecer y fomentar una opción multifactor. AAL2 exige dos factores distintos, al menos un autenticador resistente a replay y una opción resistente al phishing; para federal enterprise, esa opción debe exigirse a personal, contratistas y socios. AAL3 exige un protocolo criptográfico resistente al phishing con clave privada no exportable y requisitos adicionales de autenticador y criptografía. NIST SP 800-63B-4, §§2.1–2.3
Un autenticador multifactor puede satisfacer dos factores en un solo dispositivo: posesión de la clave y un factor de activación local. Otra combinación usa contraseña más autenticador criptográfico de un factor. El conteo debe seguir el protocolo y la política; «teléfono más portátil» no garantiza dos factores si el teléfono sólo recibe una aprobación sin las propiedades requeridas.
AAL no es Identity Assurance Level (IAL), Federation Assurance Level (FAL), nivel de privilegio ni clasificación de impacto. Una sesión autenticada a AAL3 puede carecer de autorización para una factura; una operación de bajo privilegio puede no necesitar ese AAL. La selección se hace por riesgo y requisito, y el RP conserva la decisión de autorización.
El ciclo de vida decide el assurance efectivo
El binding asocia un autenticador con una cuenta. El Credential Service Provider (CSP) debe mantener el registro de autenticadores y eventos significativos, permitir múltiples autenticadores y proteger el alta posterior con un nivel apropiado. Al añadir uno, debe notificarse al suscriptor por un mecanismo independiente de la transacción. NIST SP 800-63B-4, §4.1.2.1 y §4.6
Una política defendible cubre:
- alta inicial y quién estableció la identidad de la cuenta;
- incorporación de autenticadores adicionales y step-up requerido;
- inventario visible, nombre comprensible, última utilización y procedencia;
- pérdida, sospecha de duplicación, reemplazo, expiración y revocación;
- notificación independiente y ventana para reportar un binding no reconocido;
- recuperación, códigos de un solo uso y soporte humano;
- cierre de sesiones y tokens derivados cuando cambia la confianza en la cuenta.
La recuperación no es una comodidad exterior al modelo: es otra forma de recuperar capacidad de autenticación. Si soporte puede reemplazar una passkey usando sólo datos biográficos o correo protegido por contraseña, el atacante escogerá ese camino. Un saved recovery code debe protegerse como autenticador, almacenarse de forma segura, invalidarse después de usarlo y no aparecer en telemetría. Para códigos emitidos o enviados mediante contactos de recuperación, la política debe fijar vigencia, intentos y estado de consumo conforme al mecanismo. Mantener dos autenticadores fuertes independientes suele reducir la necesidad de un bypass.
El fallback puede ser explícito y acotado. Un servicio podría permitir TOTP para lectura de bajo impacto, pero exigir WebAuthn con UV para cambios de autenticadores y transferencias. Eso no vuelve resistente al phishing toda la cuenta: define rutas con un assurance distinto. La interfaz, la sesión y la autorización deben conservar el método y la frescura (freshness) de autenticación para que la operación sensible no herede silenciosamente una sesión creada por el fallback.
La revocación debe alcanzar la asociación del autenticador y, según el incidente, sesiones y material de recuperación relacionados. Eliminar una clave pública de la cuenta impide nuevas assertions verificadas con ella, pero no invalida automáticamente cookies ya emitidas. De modo inverso, cerrar una sesión no desregistra el autenticador.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Caso trabajado: probar la propiedad y buscar el downgrade
Northstar formula un claim inicial: «las cuentas de tesorería usan MFA resistente al phishing». Es demasiado amplio. La revisión construye una matriz por ruta:
Desliza horizontalmente para consultar todas las columnas.
La prueba positiva registra una credencial en login.northstar.example, emite un challenge único, exige UV y verifica todos los campos de la assertion. La prueba negativa presenta el flujo, dentro de un entorno aislado, desde un origin controlado para la prueba pero no autorizado por la política del RP: el cliente no debe permitir usar la credencial con el RP ID legítimo y el servidor no debe aceptar origin, RP ID hash o challenge incorrectos. La regresión intenta challenge reutilizado, UV ausente, credencial revocada y estado BE/BS incompatible con la política.
Después se prueban los bordes. ¿Puede una sesión TOTP añadir una passkey? ¿Puede soporte restablecer la cuenta sin una evidencia equivalente? ¿Un recovery code crea una sesión capaz de transferir fondos? ¿Revocar la credencial cierra sesiones existentes? ¿La telemetría distingue registro, assertion, recuperación y cambio de autorización? Si cualquiera ofrece autoridad equivalente con assurance menor, el claim debe rebajarse o el flujo debe remediarse.
La conclusión adecuada queda acotada: «Entre T1 y T2, el login de tesorería por la ruta W exigió una assertion WebAuthn Level 3 con challenge de un solo uso, origin O, RP ID R y UV; el RP verificó firma y flags contra la credencial C. Las pruebas negativas de origin, challenge, UV y revocación fueron rechazadas. El claim no cubre endpoints comprometidos, sesiones emitidas previamente, recuperación, autorización de transferencias ni otras rutas listadas». Eso es más útil que una insignia de “MFA activado”.
Límites y transferencia
La autenticación resistente al phishing reduce una clase importante de captura y relay de credenciales; no hace confiable al navegador, no corrige una aplicación vulnerable, no protege una sesión robada después del login y no autoriza acciones. Attestation puede informar sobre el autenticador, no sobre toda la cadena. UV informa de una verificación local, no identifica el método ni prueba intención para datos de negocio específicos. Una passkey sincronizada y una ligada al dispositivo tienen fronteras diferentes, no una jerarquía universal.
Al diseñar para workforce (personal interno), banca, servicios públicos o consumidores, se conserva el mismo razonamiento: inventariar rutas, identificar factores y autenticadores, reconstruir mensajes y binding, seleccionar el AAL, examinar ciclo de vida y probar downgrade. Cambian la amenaza, la población, accesibilidad, dispositivos administrados y tolerancia a recuperación; no cambia la obligación de declarar qué propiedad se verificó.
El modelo final cabe en una pregunta compuesta: ¿qué autenticador produjo qué output, ligado a qué sesión y verificador, bajo qué política de ciclo de vida, y qué camino alternativo puede obtener la misma autoridad? Sólo después de responderla tiene sentido decir MFA, passkey o phishing-resistant.