Account Takeover and MFA

Pathrule3 Rules • 1 Memory • 1 Skill

Account takeover defense must cover the full account lifecycle because strong sign-in MFA is bypassed when recovery, enrollment, sessions, or support flows are weaker. This bundle sets anti-enumeration responses, attempt budgets, phishing-resistant factor policy, session revocation, and verified recovery. Unlike Auth Sessions JWT OAuth, it focuses on adversarial takeover and step-up decisions rather than token and identity-protocol architecture.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

review-account-takeover

src/

auth/

Apply attempt budgets to every authentication path

Require phishing-resistant factors for high-risk access

Authentication assurance belongs to the session

api/

Treat recovery and factor changes as security events

Rules

Apply attempt budgets to every authentication path/src/authhighstrictSign-in, recovery, enrollment, verification, and resend operations share abuse-aware attempt controls.

1	Sign-in, recovery, enrollment, verification, and resend operations share abuse-aware attempt controls. Attackers move to the least protected endpoint when only the primary password form is throttled. Enforce this boundary in /src/auth so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Key budgets with account, network, device, and operation signals without revealing whether the account exists.
4	- Use progressive delay or challenge without letting an attacker lock a victim out indefinitely.
5	- Bound verification-code generation and checks separately so resend does not reset guesses.
6	- Preserve capacity for legitimate recovery and support while detecting distributed low-rate attacks.
7
8	Verification: Run credential stuffing, code guessing, resend, account rotation, and shared-network scenarios; confirm responses do not enumerate users and alerts group related activity.

Require phishing-resistant factors for high-risk access/src/authhighstrictPrivileged accounts and sensitive actions use factors bound to the legitimate origin and verifier.

1	Privileged accounts and sensitive actions use factors bound to the legitimate origin and verifier. One-time codes and approval prompts can be relayed or fatigued, leaving a nominal MFA deployment vulnerable to convincing phishing. Enforce this boundary in /src/auth so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Prefer passkeys or hardware-backed public-key authenticators for administrators and other high-impact roles.
4	- Treat email and SMS as recovery or transitional factors according to the product risk model, not equivalent proof for every action.
5	- Use step-up authentication for payouts, credential changes, data exports, role grants, and other sensitive operations.
6	- Bind step-up approval to the exact action and show the user what will change before confirmation.
7
8	Verification: Attempt the privileged flow with a normal session, a relayed code, and the approved origin-bound factor; confirm only the intended method authorizes the exact action.

Treat recovery and factor changes as security events/src/apihighstrictRecovery, password reset, factor enrollment, and factor removal trigger verification, notification, holds, and session policy.

1	Recovery, password reset, factor enrollment, and factor removal trigger verification, notification, holds, and session policy. An attacker who reaches recovery can silently replace factors and keep existing sessions, turning one weak check into durable control. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Verify recovery with evidence appropriate to account risk and never use easily discovered profile facts as secrets.
4	- Notify established channels before and after factor or recovery changes without including reusable secrets.
5	- Revoke or re-evaluate existing sessions after credential recovery and high-risk factor changes.
6	- Apply a risk-based hold to payouts, exports, role changes, or other irreversible actions after recovery.
7
8	Verification: Simulate recovery by the legitimate user and an attacker with partial profile data; verify session revocation, notifications, holds, and support evidence.

Memories

Authentication assurance belongs to the session/src/authA successful login is not a permanent assurance level because factor strength, age, risk signals, and credential changes evolve during the session.

1	A successful login is not a permanent assurance level because factor strength, age, risk signals, and credential changes evolve during the session. Record which factors were used, when authentication occurred, and the resulting assurance in server-side session state or verifiable claims.
2
3	Recompute authorization for sensitive actions using required assurance and maximum authentication age. Invalidate remembered-device and assurance state when credentials, factors, recovery, or account risk change. Do not let a client-set flag assert that step-up already happened. Keep the decision explicit at /src/auth; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /src/api for action-specific step-up rules and /tests/security for takeover scenarios. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

review-account-takeover/rootReview account entry, recovery, factor, session, and support flows as one takeover surface.

1	---
2	name: review-account-takeover
3	description: Review account entry, recovery, factor, session, and support flows as one takeover surface.
4	---
5
6	# Review Account Takeover
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Inventory every way to authenticate, recover, enroll or remove a factor, remember a device, revoke a session, and ask support for access.
11	2. Compare enumeration resistance, attempt budgets, verification strength, notifications, and audit evidence across those flows.
12	3. Exercise credential stuffing, recovery with partial data, factor replacement, session theft, and post-recovery sensitive actions in a test environment.
13	4. Record gaps by takeover path, prioritize the shortest successful path, and verify fixes with signals that distinguish attack from user error.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents add MFA to the happy-path login but leave password reset, factor replacement, remembered devices, session theft, and support recovery as easier takeover routes.

Built for Teams operating user accounts with password, passkey, federated, or multi-factor authentication.

Keeps your assistant from:

Account enumeration through login and recovery responses
A weaker recovery flow bypassing stronger sign-in factors
Factor changes or password resets that leave attacker sessions active

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25