Security
Designing account recovery that is not the weakest link
Password reset tokens, what to revoke after a reset, why recovery bypasses MFA so often, and how to keep recovery as strong as sign-in.
The short answer
Account recovery is an authentication path, so it must be as strong as sign-in. Use single-use, short-lived, high-entropy reset tokens sent to a verified channel; never reveal whether an account exists; require MFA where it is enrolled; and when the password changes, revoke every existing session and refresh token so an attacker already inside is removed.
Sources last reviewed .
Reset tokens
- Generated by a CSPRNG, stored hashed, single-use, expiring in minutes to an hour.
- Delivered only to an already-verified address; never accept a new address in the reset request.
- Not placed in a URL that will be logged by third parties, and not leaked via the Referer header on the reset page.
After the reset
Revoke all sessions and refresh tokens, notify the user through a separate channel, and log the event. A reset that leaves the attacker's existing session alive has not recovered anything.
In Authreads
How this applies to Authreads
Password reset in Authreads is token-bound and atomic with session revocation: the reset and the revocation of existing sessions happen together.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.