Los desafíos MFA de corta duración se vinculan a una sesión pendiente, el paso adicional protege acciones sensibles, los códigos de recuperación son de un solo uso y la repetición de la contraseña no puede omitir un segundo factor en curso o requerido.
Estado del paquete: contexto de referencia listo para revisión humana. El contrato y los escenarios de prueba están completos, pero no se afirma que una implementación adoptante los haya superado.
Decisión
Después de que el primer factor tiene éxito, el navegador mantiene solo una sesión pendiente que no puede llamar a APIs autenticadas. Un registro de desafío de corta duración vincula esa sesión pendiente a un método como TOTP. Completar el desafío promueve la sesión pendiente, usando la rotación relacionada del ciclo de vida de la sesión, a una sesión aal2. Las acciones sensibles en el perfil requieren un nuevo desafío de paso adicional incluso si aal2 fue otorgado anteriormente. Los códigos de recuperación se almacenan hasheados, se usan una vez y se ingresan en un control separado para que no se mezclen con los dígitos TOTP. Reenviar la contraseña mientras un desafío está pendiente no omite la MFA.
Alcance
- Emisión de desafíos, vinculación, expiración, presupuesto de intentos, paso adicional, consumo de códigos de recuperación y estados UX para aplicaciones de navegador.
- Promoción de sesiones pendientes a sesiones duraderas mediante el paquete de sesión relacionado.
Fuera de este bloque
- Formato de cookie de sesión más allá del disparador de promoción, inscripción TOTP, ceremonias WebAuthn y OTP por SMS (no en este perfil).
Contrato
- Se requiere un id de desafío para completar la MFA y está vinculado a una sesión pendiente; es inútil en otra sesión.
- El ttl del desafío y los intentos máximos se aplican del lado servidor; la UI no puede extenderlos.
- Las acciones de paso adicional en el perfil no se confirman hasta que un nuevo desafío tiene éxito y el nivel de autenticación de la sesión es aal2.
- Los códigos de recuperación consumen su digest en el primer éxito y no pueden reutilizarse.
- La repetición de la contraseña durante un desafío pendiente no emite una sesión completa.
- La pantalla pendiente mantiene el foco del teclado en el campo de código y anuncia el bloqueo sin revelar si el secreto TOTP existe.
Guía de implementación
- Almacenar sesiones pendientes separadas de las sesiones activas para que el middleware de API pueda rechazarlas. Hashear los códigos de recuperación con una sal única y mostrar el conteo restante después del éxito.
- En el paso adicional, capturar el id de la acción prevista para que un desafío completado no pueda aplicarse a un cambio de pago diferente.
Manejo de fallos y salvaguardas
- Los intentos agotados expiran el desafío y requieren un nuevo primer factor. Si la promoción falla después de un TOTP válido, no consumir un código de recuperación.
- El soporte para dispositivos perdidos no debe convertirse en un bypass solo con contraseña.
Verificación y operaciones
- Las pruebas UX completan el paso adicional en el cambio de pago y prueban que la marca de tiempo de la mutación es posterior a aal2. Reutilizar un código de recuperación y esperar fallo. Repetir la contraseña durante el estado pendiente y esperar que siga pendiente.
Los ejemplos con apariencia ejecutable en este paquete son fixtures y contratos de aceptación. Ejecute
python tools/validate.py desde la raíz de la colección para verificar la estructura y metadatos del paquete; luego
implemente y ejecute los escenarios en el repositorio objetivo.
Suposiciones de adopción
- Los nombres y valores numéricos en
example.yamlson un perfil de adopción, no valores predeterminados universales. - El equipo adoptante debe mapear actores, clases de datos, vocabulario de errores y propiedad a su sistema.