Códigos de respaldo y cambio de factor

Un código de respaldo es la salida de emergencia cuando el segundo factor se pierde, y por eso vale lo mismo que él. NIST SP 800-63B (revisión 4) pide que los códigos de recuperación que la persona guarda tengan al menos 64 bits de aleatoriedad, que cada uno sirva una sola vez y que se almacenen como huella. Seis dígitos dan un millón de combinaciones, unos 20 bits: suficiente para un código que vence en minutos, muy poco para uno que vive meses en un cajón.

Hay dos reglas más que el código suele olvidar: al regenerar los códigos, los anteriores dejan de servir, y cada vez que se usa o se reemplaza uno, se avisa al titular.

El titular regeneró sus códigos en agosto porque perdió la hoja de marzo. Si el portal no invalida el lote viejo, esa hoja perdida sigue siendo una llave de su cuenta. Lee respaldo.py para ver qué hace la generación con los lotes anteriores y qué recorre la validación, y luego cruza lotes-TNG-40733.txt con linea-de-tiempo.txt.

Cambiar el factor es la acción que convierte un acceso de una noche en un acceso permanente: desde ese momento, los códigos llegan a quien hizo el cambio. Por eso la línea de tiempo se lee alrededor de ese evento: qué pasó justo antes y desde dónde.

NIST SP 800-63B (revisión 4) pide que, cuando se vincula un autenticador nuevo a una cuenta, se avise al titular por un canal independiente de esa misma operación, y que vincularlo exija autenticarse al nivel que corresponde. La razón es simple: el aviso existe para el titular legítimo, y si llega solo al canal que se acaba de registrar, lo recibe quien hizo el cambio.

Abre cambio-factor.py y sigue a quién se envía el mensaje de confirmación.

La madrugada del 6 de octubre encadenó cuatro debilidades: un lote viejo aún vigente, un cambio de factor que solo pedía sesión, un aviso que no llegó al titular y un beneficiario cambiado sin pedir nada más. Todas se corrigen, pero el informe tiene que decir cuál habría impedido el resto.