Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future

Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future

Speakers: Sidraf and Gabby (with contributions from Amal and academic partner Janne); researchers affiliated with Aalto University

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=PtVGiROEBAM

Reading time: ~9 minutes

Type: Briefing

TL;DR

Researchers from Aalto University audited account recovery flows across the most widely used websites using a structured framework called Artha, discovering that recovery mechanisms — intended as a security fallback — are systematically insecure by design. Three adversary models were demonstrated across eight distinct attack scenarios, including parallel session attacks, arms race attacks, and permanent lockout attacks, all exploitable without any code, exploits, or access to the victim's credentials. The findings expose a structural gap: authentication security has advanced rapidly (from passwords to passkeys), while account recovery still relies on legacy channels like email and SMS.

Introduction

Four out of five users have forgotten a password to at least one online account in the past 90 days. Twenty-five percent of internet users need account recovery on a daily basis. These numbers illustrate why account recovery is a feature of nearly every web service — and why it is almost universally treated as a usability problem rather than a security one.

The researchers argue that account recovery is insecure by design. Recovery channels (email, SMS, backup codes) are not under the service provider's control and cannot be verified in real time. A service cannot distinguish whether a recovery request is coming from a locked-out legitimate user or an adversary who has compromised that user's recovery method. Meanwhile, the entire evolution of authentication — from passwords to passphrases to MFA to passkeys — has not touched how recovery works. The weakest link in an otherwise strengthened authentication chain is the recovery fallback, which in most cases still relies on an unauthenticated email link or SMS OTP susceptible to SS7 attacks and SIM swap fraud.

The Artha Auditing Framework

To systematically analyze account recovery, the team developed Artha, a structured auditing framework that maps all possible account states and transitions across a recovery lifecycle. Account states vary considerably: accounts may exist with only a username and password (no email or phone on file), with unverified recovery methods, with multiple verified methods, or with MFA — and each state creates different recovery paths with different security properties.

▶ Watch: Framework and Account State Modeling (10:01)

The research team defined three adversary archetypes:

• Eve: Controls the victim's recovery method and wants persistent, stealthy access — observing activity without triggering account takeover.
• Mallory: Controls the recovery method and wants to permanently displace the legitimate user (kick Alice out and take the account).
• Chad: Knows the recovery method but only wants to harass — triggering recovery requests to create suspicious activity and lock the account.

The test setup used two distinct environments: a benign one mimicking the user's normal browser and location, and a semi-malicious one on a different machine, browser, and proxy to simulate suspicious behavior. Nine test case families were defined, ranging from no-recovery-method accounts through multi-factor, multi-method configurations, covering session behavior, MFA interaction, and activity visibility.

Design Flaws Discovered in the Wild

The first class of findings was design flaws — structural problems in how websites implement recovery that create exploitable conditions regardless of attacker sophistication.

▶ Watch: Design Flaw Categories (16:01)

Unverified recovery methods: Many websites allow users to add a recovery email or phone without verifying they actually control it. A typo at account creation (e.g., [email protected] instead of the correct address) either leaves the account unrecoverable or — if the mistyped address belongs to someone else — allows that third party to take over the account. Verification requirements were inconsistent even on the same platform: sometimes required when adding a method, sometimes skipped.

Recovery without credential change: Some sites complete a recovery flow without requiring the user to set a new password — offering a skip option instead. This enables a stealthy attack: an adversary (Eve) who controls the recovery channel can complete recovery without changing the password, gaining a session that the legitimate user Alice never notices. Alice remains logged in and unaware; Eve has parallel access.

Parallel sessions not terminated: When a recovery is completed, many sites do not terminate other active sessions. Adversary Eve can trigger recovery, obtain the token from the compromised recovery channel, complete the flow, and have full access to Alice's account while Alice continues browsing without any indication that something has happened. The researchers called this the parallel session attack.

Weak process checks: Some sites use heuristics — "recovering from a trusted device" — to reduce friction, loosening recovery requirements when the request comes from a previously used machine. This weakens the process for any attacker who has intermittent physical or logical access to the victim's device.

Novel Attack Scenarios

Beyond standard design flaws, the research identified several attack patterns that are not commonly discussed in account security literature.

▶ Watch: Arms Race Attack and Permanent Lockout (20:01)

The Arms Race Attack: If Mallory controls Alice's recovery method and changes Alice's password, Alice will notice she can't log in and trigger a recovery herself. The service provider has no way to distinguish which party is the legitimate user — both prove possession of the recovery channel. Each party can recover the account from the other, creating an arms race. The race ends when Mallory changes the recovery settings themselves, permanently locking Alice out of her own account.

Permanent Lockout via MFA Bypass: Some sites enforce MFA after recovery is complete — at the login step. This seems protective: Mallory can complete recovery and change the password, but when she tries to log in, MFA stops her. However, if trusted devices are not reset upon password change, and Mallory has physical access to Alice's trusted device even briefly, she can bypass MFA entirely (the trusted device prompt is skipped), change recovery settings, and lock Alice out permanently. The researchers call this the permanent lockout attack.

MFA Not Used During Recovery: Even on sites that implement MFA, MFA was typically enforced only at login — not during the recovery flow itself. This means an adversary who controls the recovery channel can complete a full account recovery, change the password, and only be stopped at the final login step if they lack the MFA factor. Mallory can still disrupt Alice: even if Mallory cannot get in, Alice's next login fails (wrong password), forcing Alice to trigger another recovery.

Token Validity Windows: The team observed recovery tokens valid for up to seven days — a window so long it allows extensive reconnaissance and attack preparation. Standard good practice calls for tokens expiring within minutes.

Best Practice Recommendations

The Artha framework produced a set of concrete recommendations spanning the entire recovery lifecycle.

▶ Watch: Recommended Recovery Flow (28:03)

Account setup: Require at least two verified authentication factors of different types from account creation. At minimum, use email or phone as the username itself (serving as an implicit verified recovery method) rather than allowing username-only accounts.

Recovery triggering: Because triggering is unauthenticated, rate-limit aggressively, require CAPTCHA or human verification, and slow down the process (prohibit copy-paste of recovery method identifiers to force deliberate human entry). Do not display recovery method details on the trigger screen — attackers who know a username should not be able to enumerate the associated email address.

Recovery processing: Require two-factor verification during the recovery flow itself — not just at login afterward. Batch both verification steps together to prevent partial-completion attacks. Terminate all existing sessions (login sessions, incomplete recovery sessions, and parallel recovery sessions) upon successful recovery. Forget trusted devices. Require a password change as part of the flow; if a skip option must exist, make the associated risk explicit and visible. Recovery tokens should expire within minutes and be non-extendable.

Alerts: Notify the user through all available channels whenever a recovery is triggered, completed, or results in a security-relevant change. Alert content should specify the type of event, the next steps available to the user, and relevant security risks (including specific attack types the user may be experiencing). Maintain a tamper-evident, read-only activity log the user can review — but cannot modify — so they can identify and report suspicious activity.

▶ Watch: Alert Content and Activity Logging (34:03)

The ideal recovery flow in summary: trigger → two-factor verification → mandatory credential change → terminate all sessions and trusted devices → security review nudge → account access.

Notable Quotes

"Account recovery is actually insecure by design — mainly because these recovery channels are not directly under the control of the service provider, which means they can never be able to know with one hundred percent surety that the requests they are getting are from an adversary or a benign user." — Sidraf, 06:00

"Irrespective of how strong the authentication has made progress, the recovery method anchors the whole thing to a weak point." — Sidraf, 06:00

"The service provider has no way of knowing which one of these is the legit user — because both are proving ownership of the recovery method. The arms race ends when Mallory manages to change the recovery settings and permanently kicks Alice out." — Gabby, 20:01

"Weaknesses in account recovery go much beyond security or hacking. Think of stalkers, intimate partner violence, or co-shared devices. Take account recovery security seriously." — Sidraf, 36:03

Key Takeaways

• Account recovery is the weakest link in modern authentication. No matter how strong the primary authentication factor (passkeys, hardware tokens), an attacker who controls the recovery channel can bypass it entirely. Authentication security is only as strong as its recovery fallback.
• Unverified recovery methods create silent vulnerabilities. A recovery email that was never verified — due to a typo, an old address, or a skipped verification step — may belong to a stranger who can take over the account. Verification must be mandatory and consistent.
• Parallel session attacks require no credentials and leave no trace. An adversary who controls the recovery channel can gain access to a live account without the victim noticing anything. Sites must terminate all sessions on recovery completion.
• MFA during recovery is not the same as MFA at login. Applying MFA only at the login step leaves the recovery flow itself unprotected. Two-factor verification must be part of the recovery process, not appended to it.
• Recovery token validity windows should be measured in minutes, not days. A seven-day recovery token is an open invitation. Tokens should be single-use, time-bound to minutes, and tied to the session in which the recovery was initiated.

Slides

No slides PDF was available for this talk. The research framework (Artha) and full analysis are described in the academic work conducted in partnership with Aalto University.