Un correo con la contraseña demuestra reversibilidad, no un esquema

Un servicio que envía por correo la contraseña actual de un usuario ha demostrado una cosa: puede obtener ese secreto en una forma que puede enviar. No ha demostrado qué columna, algoritmo o biblioteca lo produjo. La distinción importa porque el hallazgo es real y la conclusión que la gente extrae de él suele ser demasiado concreta. La reversibilidad en algún punto del camino es el mecanismo; un formato de almacenamiento supuesto no lo es.

Mantén la evidencia en ese nivel y el resto de la revisión seguirá siendo precisa.

Qué demuestra devolver el secreto antiguo

Un verificador de un solo sentido no puede producir la contraseña original, porque se diseñó para no ser invertible. Si el servicio puede enviar la contraseña por correo, en ese momento tiene material del que se puede recuperar la contraseña, o intercepta y guarda el texto plano antes de aplicar el hash. En cualquier caso, la ruta de recuperación es reversible, y eso es un hallazgo de seguridad genuino. No dice nada sobre si la misma base de datos usa un hash costoso para otras columnas.

Fíjate también en el caso intermedio: un blob cifrado almacenado con una clave que guarda la aplicación es reversible en la práctica, aunque la palabra cifrado suene tranquilizadora en un informe.

Por qué es un hallazgo de diseño y no un mapa de almacenamiento

El correo demuestra la recuperabilidad y no identifica el esquema exacto. Puede ser texto plano, cifrado determinista, una rutina de ofuscación de un proveedor o un almacén de credenciales separado que solo se usa para la recuperación. Distintas partes de un producto suelen usar almacenamiento distinto. Asignar un algoritmo con base en un solo correo es el tipo de afirmación que se derrumba en una reunión de seguimiento.

Lo que puedes decir es más estrecho y más útil: esta ruta puede recuperar el secreto, así que el producto no puede afirmar que no existe ninguna credencial recuperable. Todo lo demás necesita la evidencia del operador.

Construye el restablecimiento en torno a la autorización

Un restablecimiento resuelve otro problema: demostrar que quien lo solicita puede elegir una contraseña nueva. La guía de OWASP al respecto describe tokens o códigos de un solo uso generados de forma segura con una caducidad adecuada, y trata la etapa de solicitud como algo que debe protegerse contra la enumeración y la inundación. Una solicitud no autenticada no debe cambiar la cuenta por sí sola. Valida la autorización antes de aceptar el reemplazo y haz que el token quede inutilizable tras un uso correcto.

El canal de correo forma parte del modelo de seguridad. Poseer un nombre de cuenta no demuestra nada, y un flujo de restablecimiento que revela si una cuenta existe le entrega a un atacante un directorio con el que trabajar.

Invalida aquello que protegía la contraseña

Cambiar una contraseña no termina automáticamente con el acceso que concedía. Las sesiones VPN activas, los dispositivos recordados y los tokens emitidos por el servidor pueden tener cada uno su propio comportamiento de invalidación. Decide deliberadamente cuáles deben terminar y verifica que la implementación lo hace, porque un usuario que supone que un restablecimiento lo desconectó de todas partes suele equivocarse. Registra esa decisión junto con el flujo.

Para los operadores: documenta qué componente verifica la solicitud, cuál cambia la credencial y cómo se gestionan las sesiones relacionadas. Para los usuarios: protege el canal de recuperación legítimo y trata cualquier mensaje que devuelva una contraseña como sospechoso.

La evaluación precisa es corta: qué demuestra el mensaje, qué sigue siendo desconocido y si la recuperación sustituye el acceso mediante un proceso controlado.