Password Reset and Account Recovery Security Testing

Short answer

Account recovery must not become a weaker side door to login. Even without the password, an attacker may take over an account through enumeration, predictable reset tokens, token reuse, support bypasses, or incomplete session revocation. A sound assessment follows every state transition from request creation to use of the new credential.

Password reset, email change, and MFA recovery require different assurance levels. Treating them as buttons on one generic form can let a user who resets one factor silently remove the others.

Limit account discovery and request flooding

Return the same HTTP response and a similar timing profile for existing and nonexistent email addresses. Compare response body, status, length, and latency. The user should learn that a message may have been sent without the response disclosing that an account exists. Rate limits can use account, device, IP, and risk signals, but must not let an attacker lock a victim out as a denial-of-service tactic.

A reset request should not change account state, lock the account, or terminate sessions. Changes should happen only after proof of ownership and presentation of a valid reset token. Queueing and anti-abuse controls should manage floods without revealing account status.

Token, URL, and browser boundaries

Reset tokens should be cryptographically random, sufficiently strong, single-use, bound to a user, and time-limited. Store a protected verifier rather than the raw token where appropriate. After use, expiry, or issuance of a replacement, test the old token. Two concurrent reset submissions with the same token must not both succeed.

Build reset URLs from a trusted fixed origin, not the Host header, and use HTTPS. If the token is in a query string, reduce exposure through browser history, access logs, analytics, third-party images/scripts, and the Referer header. Consider no-referrer, a strict CSP, and removing third-party content from the reset page. Consuming a token on the first page load can lock out a user when an email scanner prefetches the link; complete the proof step through an explicit user action.

Sessions and MFA after reset

Notify the user after a password change; never send the new password by email. Define when the old password and potentially stolen refresh/session tokens stop working. For high-risk accounts, revoking sessions, showing active devices, and requiring a fresh login may be appropriate. Choose based on product risk and explain the behavior clearly.

MFA recovery should not be an automatic downgrade through a weak password reset. Review single-use backup codes, consistent support identity checks, and whether recovery email or phone changes require a delay or extra approval. Security questions alone are weak proof; answers may be public or easy to guess.

Test case	Safe expectation
Registered and unregistered email	Same external response and similar timing
Valid token submitted twice	Second use is rejected
Old token after replacement	Revoked token no longer works
Reset page loads third-party content	Token does not leak via referrer or analytics
Old session after reset	Revoked or requires controlled reauthentication
Lost MFA or support request	Documented, auditable, strong verification

Assessment and evidence plan

Diagram password, email, passkey, and MFA recovery separately.
Test enumeration, timing, flooding, token expiry, replay, and concurrent use.
Review leakage through host handling, referrer, browser history, logs, and analytics.
After reset, exercise the old password, session, refresh token, and MFA factors.
Review support intervention in a test environment for roles, approval, and audit trail.
Report which factor was bypassed and which sessions remained active.

Destek, email değişimi ve yüksek riskli hesaplar

Müşteri desteği bir kurtarma bypass’ı olmamalıdır. Temsilcinin yalnızca e-posta erişimi veya arayan kişinin verdiği kişisel bilgilerle MFA’yı kapatabildiği senaryoyu değerlendirin. Yüksek etkili işlemlerde görev ayrılığı, ikinci onay, doğrulanmış callback kanalı ve değiştirilemez audit kaydı düşünülmelidir. Destek ekibinin gördüğü kanıt, saldırganın sahte belge ya da sosyal mühendislikle kolayca üretebileceği bilgiye dayanmamalıdır.

E-posta adresi değişikliği de kimlik değişimidir. Eski adrese bildirim gönderin, yeni adrese sahiplik doğrulaması isteyin ve yüksek riskli hesaplarda her iki kanaldan onay veya gecikme uygulamasını değerlendirin. Reset akışında e-posta normalizasyonu login ve hesap bağlama politikasıyla tutarlı olmalıdır; farklı adreslerin aynı hesaba yanlış eşlenmesi ayrı bir hesap ele geçirme yolu açabilir.

For an assessment that includes identity and session flows, see our application security testing service.