Account recovery: password resets, help-desk resets and account linking

Recovery exists because normal authenticators may be lost. That makes it a deliberate alternate path to control of an account. An attacker does not need to defeat the strongest login method if a weaker reset, support, or linking path can install a new credential instead.

Draw the authority transition: identify the target account, prove control of an approved recovery factor, authorize a specific recovery action, replace or bind credentials, revoke appropriate prior authority, and notify through established channels. Keep account discovery separate from the proof. Knowing an email address or personal biographical fact is not proof of current account control.

Account linking creates a different but related transition: a new external identity becomes a way to enter an existing local account. The durable external identifier is generally the issuer and subject pair under the chosen federation protocol. A matching email string is useful discovery information but does not, by itself, authorize that transition.

A reset request should produce a response that does not disclose whether the account exists, in its body, status, headers or timing. Apply abuse controls without creating a simple account lockout weapon. Deliver a single-use token of at least 128 random bits through the established recovery channel, and keep only its hash in the recovery store. Build the link from the configured application origin: a link built from the request’s Host header lets an attacker who submits a reset with a forged host receive the victim’s token.

Store the token’s account, purpose, expiry, and consumption state. A password-reset token must not become an email-change or account-linking token merely because every handler accepts the same token syntax. Compare the requested action with the stored purpose and use server-selected account state.

The reset operation should atomically verify and consume the proof while committing the permitted change. A read-then-write sequence can allow two concurrent requests to reuse one token. Define what happens if token consumption succeeds but the password update fails; a database transaction or explicit recoverable state machine prevents ambiguous partial completion.

Do not automatically treat a reset link visit as a complete login unless the intended policy supports that and has been carefully designed. Link scanners may visit URLs before the user does. Keep irreversible consumption associated with an intentional protected action rather than an incidental page fetch.

After a successful reset, invalidate relevant sessions, refresh grants, and pending recovery or enrollment transactions according to the application policy. Notifications should go to established contact points and contain enough context to detect an unexpected change without exposing the new credential. Recovery may warrant a temporary restriction on high-impact actions. The session guide at /domains/identity-crypto/authentication/session-lifecycle/ covers revoking sessions server-side.

Creation stores only a hash; redemption is one conditional update that checks purpose, expiry and unused state and returns the account in the same statement, so two concurrent requests cannot both succeed. The password change and a session-version bump commit in the same transaction. Tested with Python 3.14 and SQLite 3.53 (RETURNING needs SQLite 3.35 or later), including eight concurrent redemptions with exactly one winner and the exact expiry boundary. The password reset token lab at /labs/recovery/ practices the same race.

import hashlib
import secrets
import sqlite3
import time

RESET_URL = "https://app.example/reset?token="  # from configuration, never from the Host header
TTL_SECONDS = 30 * 60


def digest(token: str) -> str:
    return hashlib.sha256(token.encode()).hexdigest()  # store only this; the token is never kept


def create_reset(db: sqlite3.Connection, account_id: int) -> str:
    token = secrets.token_urlsafe(32)  # 256 bits from the operating system CSPRNG
    with db:
        db.execute(
            "INSERT INTO resets (token_hash, account_id, purpose, expires_at) VALUES (?, ?, 'password-reset', ?)",
            (digest(token), account_id, int(time.time()) + TTL_SECONDS),
        )
    return RESET_URL + token  # send to the address already on the account


def redeem_reset(db: sqlite3.Connection, token: str, new_password_hash: str) -> bool:
    now = int(time.time())
    with db:  # consume the token and change the credential in one transaction
        row = db.execute(
            "UPDATE resets SET used_at = ? WHERE token_hash = ? AND purpose = 'password-reset' "
            "AND used_at IS NULL AND expires_at > ? RETURNING account_id",
            (now, digest(token), now),
        ).fetchone()
        if row is None:
            return False  # unknown, used, expired or wrong purpose: one generic answer
        db.execute(
            "UPDATE users SET pw_hash = ?, session_version = session_version + 1 WHERE id = ?",
            (new_password_hash, row[0]),  # the version bump signs out every existing session
        )
    return True

For an authenticated local user adding a federation identity, require sufficiently recent local proof and a fresh correctly bound login with the new issuer. Attach the resulting validated issuer/subject, checked as in /domains/identity-crypto/authentication/oauth-oidc-login/, to the server-selected local account. If that external identity is already linked elsewhere, follow an explicit conflict process; do not silently merge accounts.

An unauthenticated sign-in that returns an email matching an existing account should not automatically attach itself to that account. Email verification semantics differ across issuers, domains can change hands, and address reuse can occur. Even a well-verified email does not establish all historical account ownership.

Unlinking also needs lifecycle reasoning. Removing the last usable authentication method can strand the user; removing a suspicious method while leaving attacker-created sessions alive may fail to remove the attacker. Show the remaining methods and verify control before committing a risky change.

CISA’s advisory on Scattered Spider (AA23-320A, updated July 2025) describes attackers who research an employee, call the IT help desk to have passwords and MFA reset or moved to their device, swap the victim’s SIM, and send repeated push prompts until one is accepted. CISA recommends phishing-resistant MFA such as FIDO2 or PKI, which resists all three. The help desk then needs procedures an attacker cannot talk past:

• Verify the caller through a factor already enrolled on the account, or a call back to a number on file, never through data an attacker can look up.
• Require a second approver, such as the manager, for privileged and administrative accounts.
• Send a time-limited recovery link instead of setting or reading out a password, and do not bypass enrolled MFA.
• After losing every factor, repeat identity proofing at the account’s original level before binding new authenticators.
• Treat a new phone number as a new authenticator, and check SIM-swap and number-porting signals before sending SMS codes.
• Alert the user and the security team on every factor reset, and delay high-impact actions for a cooling-off period.

Ordinary valid reset completion should change exactly the intended credential. Reuse, expiry, wrong purpose, wrong account, and concurrent double submission must fail without a second change. A generic error message alone is insufficient if another response header or behavior reveals the account.

Test linking with matching emails but different issuer/subject pairs; the result must follow the explicit linking proof, not string equality. Test an already-linked external identity and an attempt to remove the final authentication method. Capture resulting sessions and credentials so the evidence shows who retains authority after each transition.

Repair the code

Password reset token lab: Make a recovery credential single-use

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Forgot Password Cheat Sheet
2. NIST SP 800-63B-4: account recovery. SP 800-63B-4 (July 2025).
3. CISA advisory AA23-320A: Scattered Spider. 16 November 2023, updated 29 July 2025.
4. OWASP ASVS 5.0: V6 Authentication. Version 5.0.0 (May 2025).
5. IETF RFC 9700: Best Current Practice for OAuth 2.0 Security. January 2025 (BCP 240).

Reference information

Tags

Account takeoverAuthentication and sessions

SDLC phase

Development

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-6.3.7 · v5.0.0-6.3.8 · v5.0.0-6.4.3 · v5.0.0-6.4.4 · v5.0.0-7.4.3 · v5.0.0-11.5.1

CAPEC attack patterns

• CAPEC-50 at MITRE

Download this guide as Markdown

Continue exploring