Traducción. Autoritativo: fs-idn-0005-mfa.md.
Contexto
Todo incidente de credential stuffing en esta categoría termina igual: una contraseña reutilizada, sin segundo factor, y una lectura completa de una base de clientes. MFA es el control con mejor relación entre esfuerzo e incidentes evitados, y es requisito básico para cualquier plataforma B2B que guarde datos personales. Dos posturas de diseño. TOTP, no SMS. El SMS es phishable, vulnerable a SIM-swap y cuesta por mensaje; TOTP funciona sin conexión, no cuesta nada y es lo que ya hace cualquier app autenticadora. Y los códigos de recuperación son la vía de recuperación, no el soporte. Un reset de MFA mediado por soporte es un objetivo de ingeniería social, y es la puerta que los atacantes efectivamente golpean.Alcance (normativo)
- Enrolamiento, verificación y remoción de TOTP.
- Códigos de recuperación de un solo uso, hasheados, generados como conjunto.
- Desafío de MFA durante el sign-in y en la reautenticación.
- Política de exigencia: obligatorio para roles con permisos sensibles.
- Política a nivel de organización que permite exigir MFA a todos.
Fuera de alcance (normativo)
- SMS como factor. Explícitamente no se ofrece — phishable, vulnerable a SIM-swap, y cuesta por mensaje para menos seguridad que una app gratis.
- Llaves de hardware como factor distinto. Un passkey (FS-IDN-0003) ya cubre ese terreno.
- MFA para members. Se autentican por OTP o token delegado, ambos ya de un solo uso.
- Reset de MFA mediado por soporte — ver la regla 6.
Comportamiento (normativo)
- TOTP con ventana estándar de 30 segundos y tolerancia de ±1 ventana por deriva de reloj. Un código es de un solo uso: reproducirlo dentro de su ventana se rechaza.
- El enrolamiento no se completa hasta verificar un código. Guardar un secreto sin probar que el usuario puede generar desde él deja gente afuera.
- Los códigos de recuperación se generan como conjunto de diez al enrolar, se muestran una sola vez, se guardan hasheados y cada uno es de un solo uso. Usar uno notifica al usuario.
- Con menos de tres códigos sin usar se advierte y se ofrece regenerar. Regenerar invalida todo el conjunto anterior.
- Desactivar MFA exige reautenticación y un segundo factor vigente, y notifica.
- El soporte no puede resetear MFA. Un usuario que pierde su autenticador y sus códigos se recupera vía un owner de la organización, y si el último owner es quien quedó fuera, por un proceso manual documentado con verificación de identidad deliberadamente lento. Hacerlo fácil es hacer fácil el ataque.
- Un rol con cualquier permiso
is_sensitiveexige MFA. Asignarlo a un usuario sin MFA lo otorga pero bloquea su uso hasta que enrole, y se lo explica. - Un tenant puede fijar una exigencia a nivel de organización, aplicable en el siguiente sign-in.
- El desafío de MFA tiene rate limit y bloqueo progresivo, como todo camino de credenciales.
Datos (normativo)
API (normativo)
Eventos (normativo)
identity.mfa.enabled y identity.mfa.disabled. Ambos producen además una notificación al usuario
por messaging, porque un cambio de MFA que el usuario no hizo es la señal más fuerte de que algo
anda mal.
Criterios de aceptación (normativo)
- Un código TOTP no se puede reproducir dentro de su ventana.
- Una deriva de ±30 segundos verifica; ±90 no.
- Un enrolamiento sin código verificado no deja factor activo.
- Un código de recuperación funciona una vez y notifica; el mismo falla después.
- Regenerar códigos invalida todos los anteriores.
- Asignar un rol con permiso sensible a un usuario sin MFA lo otorga y bloquea su uso hasta el enrolamiento, con razón tipada.
- Una exigencia de organización aplica en el siguiente sign-in para cada miembro.
- Desactivar MFA sin reautenticación y factor vigente se rechaza.
- Negativo: ningún endpoint de soporte, acción de admin ni herramienta de Ops resetea el MFA de un usuario.
Ejecución
Un solo slice, comando síncrono. TOTP por el plugin de Better Auth; secretos cifrados a nivel de columna. Las notificaciones van pormessaging mediante evento.