A Password Email Proves Reversibility, Not a Schema

A service that emails a user's current password has demonstrated one thing: it can obtain that secret in a form it can send. It has not demonstrated which column, algorithm or library produced it. The distinction matters because the finding is real and the conclusion people draw from it is usually too specific. Reversibility somewhere in the path is the mechanism; a guessed storage format is not.

Keep the evidence at that level and the rest of the review stays accurate.

What Returning the Old Secret Proves

A one-way verifier cannot produce the original password, because it was designed not to be invertible. If the service can email the password, then at that moment it holds material from which the password can be recovered, or it intercepts and stores the plaintext before hashing. Either way the recovery path is reversible, and that is a genuine security finding. It says nothing about whether the same database uses a costed hash for other columns.

Watch for the intermediate case too: a stored encrypted blob with a key held by the application is reversible in practice, even though the word encrypted sounds reassuring in a report.

Why That Is a Design Finding, Not a Storage Map

The email proves recoverability and does not identify the exact scheme. It could be plaintext, deterministic encryption, a vendor's obfuscation routine, or a separate credential store used only for recovery. Different parts of a product often use different storage. Assigning an algorithm on the strength of one email is the kind of claim that collapses in a follow-up meeting.

What you can say is narrower and more useful: this path can recover the secret, so the product cannot claim that no recoverable credential exists. Everything beyond that needs the operator's evidence.

Build the Reset Around Authorization

A reset solves a different problem: proving that the requester may choose a new password. OWASP's guidance for this describes securely generated, single-use tokens or codes with an appropriate expiry, and it treats the request stage as something to protect against enumeration and flooding. An unauthenticated request must not change the account by itself. Validate the authorization before accepting the replacement, and make the token unusable after one successful use.

The email channel is part of the security model. Possession of an account name proves nothing, and a reset flow that reveals whether an account exists hands an attacker a directory to work from.

Invalidate What the Password Protected

Changing a password does not automatically end the access it granted. Active VPN sessions, remembered devices and server-issued tokens may each have their own invalidation behaviour. Decide deliberately which of them must end, and verify that the implementation does it, because a user who assumes a reset signed them out everywhere is often wrong. Record that decision with the flow.

For operators, document which component verifies the request, which one changes the credential and how related sessions are handled. For users, protect the legitimate recovery channel and treat any message that returns a password as suspicious.

The precise assessment is short: what the message demonstrates, what remains unknown, and whether recovery replaces access through a controlled process.