Un correu amb la contrasenya demostra reversibilitat, no un esquema

Un servei que envia la contrasenya actual d’un usuari per correu ha demostrat una cosa: pot obtenir aquest secret en una forma que pot enviar. No ha demostrat quina columna, algorisme o biblioteca l’ha produït. La distinció importa perquè la troballa és real i la conclusió que la gent en treu sol ser massa concreta. La reversibilitat en algun punt del camí és el mecanisme; un format d’emmagatzematge suposat no ho és.

Mantingueu les proves en aquest nivell i la resta de la revisió continuarà sent precisa.

Què demostra retornar el secret antic

Un verificador d’un sol sentit no pot produir la contrasenya original, perquè es va dissenyar perquè no fos invertible. Si el servei pot enviar la contrasenya per correu, en aquell moment té material del qual es pot recuperar la contrasenya, o intercepta i guarda el text pla abans de fer el hash. En qualsevol cas, el camí de recuperació és reversible, i això és una troballa de seguretat genuïna. No diu res sobre si la mateixa base de dades fa servir un hash costós per a altres columnes.

Fixeu-vos també en el cas intermedi: un blob xifrat emmagatzemat amb una clau que té l’aplicació és reversible a la pràctica, tot i que la paraula xifrat soni tranquil·litzadora en un informe.

Per què és una troballa de disseny i no un mapa d’emmagatzematge

El correu demostra la recuperabilitat i no identifica l’esquema exacte. Pot ser text pla, xifratge determinista, una rutina d’ofuscació d’un proveïdor o un magatzem de credencials separat que només s’utilitza per a la recuperació. Parts diferents d’un producte sovint fan servir emmagatzematge diferent. Assignar un algorisme basant-se en un sol correu és el tipus d’afirmació que s’esfondra en una reunió de seguiment.

El que podeu dir és més estret i més útil: aquest camí pot recuperar el secret, així que el producte no pot afirmar que no existeix cap credencial recuperable. Tot el que vagi més enllà necessita les proves de l’operador.

Construïu el restabliment al voltant de l’autorització

Un restabliment resol un problema diferent: demostrar que el sol·licitant pot triar una contrasenya nova. La guia d’OWASP sobre això descriu tokens o codis d’un sol ús generats de manera segura amb una caducitat adequada, i tracta l’etapa de sol·licitud com una cosa que cal protegir contra l’enumeració i la inundació. Una sol·licitud no autenticada no ha de canviar el compte per si sola. Valideu l’autorització abans d’acceptar la substitució i feu que el token quedi inservible després d’un ús correcte.

El canal de correu forma part del model de seguretat. Posseir un nom de compte no demostra res, i un flux de restabliment que revela si un compte existeix dona a un atacant un directori amb què treballar.

Invalideu allò que protegia la contrasenya

Canviar una contrasenya no acaba automàticament amb l’accés que concedia. Les sessions VPN actives, els dispositius recordats i els tokens emesos pel servidor poden tenir cadascun el seu propi comportament d’invalidació. Decidiu deliberadament quins han d’acabar i verifiqueu que la implementació ho fa, perquè un usuari que assumeix que un restabliment l’ha desconnectat de tot arreu sovint s’equivoca. Registreu aquesta decisió amb el flux.

Per als operadors: documenteu quin component verifica la sol·licitud, quin canvia la credencial i com es gestionen les sessions relacionades. Per als usuaris: protegiu el canal de recuperació legítim i tracteu qualsevol missatge que retorni una contrasenya com a sospitós.

L’avaluació precisa és curta: què demostra el missatge, què continua sent desconegut i si la recuperació substitueix l’accés mitjançant un procés controlat.