Migrar un almacén de contraseñas heredado

Un sistema no guarda las contraseñas, así que no puede volver a derivarlas con un algoritmo nuevo cuando quiera. Hay dos salidas que se combinan. La primera es envolver: aplicar la función lenta sobre el resumen viejo que ya está guardado, de modo que la base deja de tener MD5 desnudos desde el primer día. La segunda es re-derivar en el siguiente ingreso correcto: en ese momento el sistema tiene la contraseña en memoria, la deriva directamente con la función nueva y abandona la envoltura, que es más débil que una derivación directa.

Las cuentas que no entran nunca se quedan envueltas para siempre. Para ellas, lo prudente es fijar un plazo y, al vencer, borrar el resumen y obligar a restablecer la contraseña por un canal verificado. Y cada fila debe guardar con qué algoritmo y con qué parámetros se derivó, para poder volver a migrar sin adivinar.

Una migración se da por terminada mirando el almacén, no el plan. Si después de envolver sigue habiendo una vía que crea cuentas con el formato viejo, la base vuelve a llenarse de lo que se quería eliminar. Y una carga masiva hecha con un script antiguo tiene el mismo efecto.

Abre estado-almacen.txt y suma, por origen, lo que sigue en el formato sin envolver.

La fase 2 depende de una sola función: la que verifica al ingresar. Si esa función solo re-deriva en una de sus ramas, el resto de las cuentas no avanza nunca, por muchas veces que sus dueños entren. El registro de ingresos lo confirma sin leer código: el formato antes y después de un ingreso correcto debería cambiar.

Abre verificar.py y contrástalo con registro-ingresos.txt.

Más de la mitad de las cuentas envueltas no ha entrado en 18 meses. No van a pasar a la derivación directa por su cuenta, y mientras sigan ahí son un MD5 envuelto que se puede atacar si la base se filtra.

El informe tiene que decir qué cambiar, en este orden de urgencia: lo que sigue creando cuentas débiles, lo que impide que la migración avance y lo que queda pendiente para la fase 3.