El flujo de olvido de contraseña bien diseñado

Un flujo de recuperación bien diseñado tiene pocas piezas y todas apuntan a lo mismo: que pedir un enlace no le diga nada a quien no es el titular y no cambie nada en la cuenta hasta que el titular demuestre que recibió el mensaje. En la práctica eso se traduce en una respuesta idéntica exista o no la cuenta, un enlace que solo sirve una vez y por poco tiempo, armado con un dominio fijo de la configuración, un cambio que ocurre solo cuando ese enlace se usa, y un aviso al titular cuando la contraseña cambia.

La guía de OWASP sobre el olvido de contraseña recoge esas mismas ideas, y MITRE agrupa sus fallos bajo CWE-640, mecanismo débil de recuperación de una contraseña olvidada. Lo que esta sala hace es buscarlas una por una en el código y en la evidencia.

Cuando la aplicación responde distinto según exista o no la cuenta, cualquiera puede usar el formulario como un directorio: prueba correos y se queda con los que existen. MITRE lo llama discrepancia observable en la respuesta (CWE-204). La diferencia no tiene que estar en el texto: puede estar en el código de estado, en una cabecera, en el tamaño o en el tiempo.

Abre respuestas-guardadas.txt y compara los dos intercambios línea por línea, no solo el párrafo final.

El enlace que llega al correo es lo único que separa a una persona de su cuenta. Si su dominio se arma con algo que viene en la petición, quien pide el enlace en nombre de otro puede influir en a qué servidor apunta el mensaje que recibe la víctima, y el token viajaría a un sitio ajeno cuando ella haga clic. El arreglo no es filtrar mejor esa entrada: es no usarla, y tomar la dirección base de la configuración.

Abre olvido.py y sigue la variable con la que se arma el enlace.

Pedir un enlace debe ser inofensivo: cualquiera puede escribir el correo de otro. Si la petición ya cambia algo en la cuenta, el formulario se vuelve una forma de dejar sin servicio a quien se quiera, sin haber tocado nunca su buzón. Las notas de soporte de esa mañana muestran justo ese efecto: asegurados sin acceso que no habían pedido nada y sin movimientos en su póliza.

Vuelve a olvido.py y busca qué ocurre antes de crear el token.

El equipo propone corregir el hallazgo de la tarea 2 devolviendo siempre el mismo mensaje y el mismo código de estado. Antes de aprobarlo, mira qué más distinguía a los dos intercambios y qué muestra el registro de la madrugada del 28 de septiembre, donde un mismo origen probó más de cuatro mil correos.