Un correo co contrasinal demostra reversibilidade, non un esquema

Un servizo que envía por correo o contrasinal actual dun usuario demostrou unha cousa: pode obter ese segredo nunha forma que pode enviar. Non demostrou que columna, algoritmo ou biblioteca o produciu. A distinción importa porque o achado é real e a conclusión que a xente extrae del adoita ser demasiado concreta. A reversibilidade nalgún punto do camiño é o mecanismo; un formato de almacenamento suposto non o é.

Mantén a evidencia nese nivel e o resto da revisión seguirá sendo precisa.

Que demostra devolver o segredo antigo

Un verificador dun só sentido non pode producir o contrasinal orixinal, porque se deseñou para non ser invertible. Se o servizo pode enviar o contrasinal por correo, nese momento ten material do que se pode recuperar o contrasinal, ou intercepta e garda o texto plano antes de aplicar o hash. En calquera caso, a ruta de recuperación é reversible, e iso é un achado de seguridade xenuíno. Non di nada sobre se a mesma base de datos usa un hash custoso para outras columnas.

Fíxate tamén no caso intermedio: un blob cifrado almacenado cunha clave que garda a aplicación é reversible na práctica, aínda que a palabra cifrado soe tranquilizadora nun informe.

Por que é un achado de deseño e non un mapa de almacenamento

O correo demostra a recuperabilidade e non identifica o esquema exacto. Pode ser texto plano, cifrado determinista, unha rutina de ofuscación dun provedor ou un almacén de credenciais separado que só se usa para a recuperación. Distintas partes dun produto adoitan usar almacenamento distinto. Asignar un algoritmo con base nun só correo é o tipo de afirmación que se derruba nunha reunión de seguimento.

O que podes dicir é máis estreito e máis útil: esta ruta pode recuperar o segredo, así que o produto non pode afirmar que non existe ningunha credencial recuperable. Todo o demais necesita a evidencia do operador.

Constrúe o restablecemento arredor da autorización

Un restablecemento resolve outro problema: demostrar que quen o solicita pode escoller un contrasinal novo. A guía de OWASP ao respecto describe tokens ou códigos dun só uso xerados de forma segura cunha caducidade axeitada, e trata a etapa de solicitude como algo que debe protexerse contra a enumeración e a inundación. Unha solicitude non autenticada non debe cambiar a conta por si soa. Valida a autorización antes de aceptar o substituto e fai que o token quede inutilizable tras un uso correcto.

O canal de correo forma parte do modelo de seguridade. Posuír un nome de conta non demostra nada, e un fluxo de restablecemento que revela se unha conta existe entrégalle a un atacante un directorio co que traballar.

Invalida aquilo que protexía o contrasinal

Cambiar un contrasinal non remata automaticamente co acceso que concedía. As sesións VPN activas, os dispositivos recordados e os tokens emitidos polo servidor poden ter cada un o seu propio comportamento de invalidación. Decide deliberadamente cales deben rematar e verifica que a implementación o fai, porque un usuario que supón que un restablecemento o desconectou de todas partes adoita equivocarse. Rexistra esa decisión xunto co fluxo.

Para os operadores: documenta que compoñente verifica a solicitude, cal cambia a credencial e como se xestionan as sesións relacionadas. Para os usuarios: protexe a canle de recuperación lexítima e trata calquera mensaxe que devolva un contrasinal como sospeitosa.

A avaliación precisa é curta: que demostra a mensaxe, que segue sendo descoñecido e se a recuperación substitúe o acceso mediante un proceso controlado.