auditing-account-recovery-and-reset-trust

Auditing account recovery and reset trust: the alternate door into every account

Every login has a back door built in on purpose: the password reset and account recovery flow. It exists so a locked-out user can get back in, which means it is, by design, a way to gain access to an account without the password. That makes it a prime takeover target, and it is frequently weaker than the front door it protects. The reset token may be guessable, long-lived, reusable, or not bound to the account, so an attacker can predict or replay it. The recovery path may verify a weaker factor than login and skip the multi-factor requirement, so recovery becomes the multi-factor bypass. The reset link's host may come from a request header an attacker controls, so the emailed token leaks to the attacker's domain. And recovery may trust an unverified email or phone change, redirecting the reset to the attacker. The audit treats recovery as an authentication path with the same rigor as login. You audit this by walking the flow and testing each trust it places.

When to use

• An application offers password reset or account recovery as a way to regain access to an account.
• Reset tokens may be weak, long-lived, reusable, or not bound to the requesting account.
• Recovery may verify a weaker factor than login, bypass multi-factor, or leak the reset link off-domain.

Scope check

Test recovery flows only against accounts and applications you own or are authorized to assess, on non-production accounts. Exercising reset attempts real credential changes, so use test accounts you control and never reset or take over an account that is not yours. If you can't name the authorization, stop.

The loop

1. Establish the intended recovery assurance first. Name what proof recovery should require and that it must be at least as strong as login, including any multi-factor requirement. This is the false-positive killer: a recovery flow with a high-entropy, single-use, short-lived, account-bound token, that enforces the same factors as login and builds the link from a server-fixed host, is correct. Name the intended assurance, then test each element.