Stop account takeover with the right MFA and login defenses

Passkeys and FIDO2 security keys. They are the only common second factors that a phishing site cannot relay, because the browser binds each signature to your domain. Next come authenticator-app codes (TOTP) and push prompts that make the user type a number from the login screen, which stop password reuse but not real-time phishing. SMS and voice codes are the weakest acceptable option, and approve-only push prompts and email codes are not acceptable under NIST SP 800-63B-4. For administrators and high-value accounts, require a device-bound security key.

Account takeover rarely defeats a second factor head-on. Attackers replay passwords leaked elsewhere, relay one-time codes through a fake login page, wear users down with push prompts, port the phone number or skip MFA through recovery. Rank each option by which of those it stops, make the strongest the default, and keep the rest as fallbacks you plan to retire.

NIST SP 800-63B-4 (final, July 2025) counts only cryptographic authenticators as phishing-resistant, because any code a user reads and types can be relayed. It requires AAL2 verifiers to offer at least one phishing-resistant option, marks SMS and voice codes as restricted, forbids email as an out-of-band authenticator and keeps synced passkeys out of AAL3.

TOTP (RFC 6238) derives a six-digit code from a shared secret and the current 30-second step. Generate a 160-bit secret and encrypt it at rest; the verifier needs the plaintext key, so a hash won't work. Keep HMAC-SHA-1, six digits and 30 seconds unless you control the app; Google Authenticator, for one, ignores other algorithm and period settings. ASVS 5.0 lists HMAC-SHA-1 as legacy, acceptable for compatibility.

Check codes against the server's clock, never a time the client sends. Allow at most one step either side for drift and typing; every extra step lengthens the time a phished code stays valid. Accept each code once: RFC 6238 says the verifier MUST NOT accept a second use, so store the last accepted step and accept only later ones. Limit failures per account across sessions. With a one-step window three of the million possible codes are valid at any moment, so an attacker making 1,000 guesses a second expects a hit in about six minutes.

The verifier below charges each attempt before checking it, so parallel guesses can't exceed the limit, and claims the matched step with a conditional UPDATE, so two simultaneous submissions of one code can't both succeed. It passes the RFC 6238 vectors and was tested on SQLite and on PostgreSQL 18 at its default READ COMMITTED isolation.

import hashlib
import hmac
import re
import secrets
import struct
import time

STEP, DIGITS, SKEW = 30, 6, 1   # 30-second steps, 6 digits, accept T-1, T and T+1
MAX_FAILURES = 10               # consecutive failures before the factor is locked
CODE = re.compile(r"[0-9]{6}")  # ASCII digits only; str.isdigit() also accepts "²" and "١"


def new_secret() -> bytes:
    return secrets.token_bytes(20)  # 160 bits; store it encrypted, never hashed


def hotp(key: bytes, counter: int, digits: int = DIGITS, digest=hashlib.sha1) -> str:
    mac = hmac.new(key, struct.pack(">Q", counter), digest).digest()
    offset = mac[-1] & 0x0F
    value = int.from_bytes(mac[offset:offset + 4], "big") & 0x7FFFFFFF
    return str(value % 10**digits).zfill(digits)


def matching_step(key: bytes, code: str, now: float) -> int | None:
    if not CODE.fullmatch(code):
        return None
    current = int(now // STEP)
    match = None
    for step in range(current - SKEW, current + SKEW + 1):
        if hmac.compare_digest(hotp(key, step), code):
            match = step
    return match


def verify_totp(db, user_id: int, code: str, now: float | None = None) -> bool:
    now = time.time() if now is None else now  # the server's clock, never the client's
    # Charge the attempt first, so parallel guesses cannot exceed the limit.
    cur = db.execute(
        "UPDATE totp SET failures = failures + 1 WHERE user_id = ? AND failures < ?",
        (user_id, MAX_FAILURES),
    )
    db.commit()
    if cur.rowcount != 1:
        return False  # no TOTP factor, or locked until recovery
    (secret,) = db.execute("SELECT secret FROM totp WHERE user_id = ?", (user_id,)).fetchone()
    step = matching_step(secret, code, now)
    if step is None:
        return False
    # Accept each time step once, and never a step older than the last accepted one.
    cur = db.execute(
        "UPDATE totp SET last_step = ?, failures = 0 "
        "WHERE user_id = ? AND (last_step IS NULL OR last_step < ?)",
        (step, user_id, step),
    )
    db.commit()
    return cur.rowcount == 1

Pin the behavior in tests: the RFC vectors, a replay inside one step, an unused older code after a newer one, the limit under parallel guessing and one code submitted many times at once.

import sqlite3
import threading

from totp import MAX_FAILURES, STEP, hotp, verify_totp

KEY, NOW = b"12345678901234567890", 1_791_616_580


def db(path=":memory:"):
    conn = sqlite3.connect(path, timeout=30, check_same_thread=False)
    conn.execute("CREATE TABLE IF NOT EXISTS totp (user_id INTEGER PRIMARY KEY, secret BLOB NOT NULL, "
                 "last_step INTEGER, failures INTEGER NOT NULL DEFAULT 0)")
    conn.execute("INSERT OR REPLACE INTO totp (user_id, secret) VALUES (1, ?)", (KEY,))
    conn.commit()
    return conn


def code(t):
    return hotp(KEY, int(t // STEP))


def test_rfc6238_sha1_vectors():
    for t, expected in [(59, "94287082"), (1111111109, "07081804"), (2000000000, "69279037")]:
        assert hotp(KEY, t // 30, digits=8) == expected


def test_replay_and_skew():
    conn = db()
    assert verify_totp(conn, 1, code(NOW), NOW)
    assert not verify_totp(conn, 1, code(NOW), NOW + 10)            # same code again
    assert not verify_totp(db(), 1, code(NOW - 2 * STEP), NOW)       # outside the window
    conn = db()
    assert verify_totp(conn, 1, code(NOW + STEP), NOW)               # phone clock 30 s ahead
    assert not verify_totp(conn, 1, code(NOW), NOW)                  # older step, never used


def test_limit_holds_against_parallel_guesses(tmp_path):
    path = str(tmp_path / "t.db")
    db(path).close()
    wrong = "000000" if code(NOW) != "000000" else "111111"
    threads = [threading.Thread(target=lambda: verify_totp(sqlite3.connect(path, timeout=30), 1, wrong, NOW))
               for _ in range(30)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    conn = sqlite3.connect(path)
    assert conn.execute("SELECT failures FROM totp").fetchone()[0] == MAX_FAILURES
    assert not verify_totp(conn, 1, code(NOW), NOW)                  # locked: right code refused


def test_one_code_cannot_win_twice_concurrently(tmp_path):
    path = str(tmp_path / "t.db")
    db(path).close()
    results = []
    threads = [threading.Thread(target=lambda: results.append(
        verify_totp(sqlite3.connect(path, timeout=30), 1, code(NOW), NOW))) for _ in range(16)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    assert results.count(True) == 1

MFA fatigue works because an approve-or-deny prompt asks nothing of the user. In September 2022, Uber said an attacker who had probably bought a contractor's password kept triggering login approval requests until the contractor accepted one; Uber believed the attacker was affiliated with Lapsus$. CISA calls this push bombing and recommends number matching as an interim step toward phishing-resistant MFA. Microsoft Authenticator now enables number matching for all push notifications.

SP 800-63B-4 goes further. The user must transfer a secret between the login screen and the device, the secret must be at least six digits, and choosing from a short list doesn't qualify, because users guess.

• Show a code on the login page, make the user type it into the app, and bind the approval to that login transaction.
• Cap the prompts sent since the last successful login, then switch to another factor (SP 800-63B-4 3.1.3.2; ASVS 5.0 6.6.4).
• Treat a denied or reported prompt as a sign the password is known: alert the security team and ask the user to change it.
• Expire push, SMS and voice secrets within 10 minutes and accept each one once.

Only as a restricted fallback. An SMS code still stops most credential stuffing, which is far better than a password alone, but SIM swaps, number porting, interception and phishing proxies defeat it. NIST SP 800-63B-4 treats SMS and voice as restricted authenticators: offer at least one unrestricted alternative, tell users the risk, and plan the move to passkeys or an authenticator app. Do not rely on SMS for administrators, account recovery of high-value accounts or anyone likely to be targeted.

SMS and voice codes fall to SIM swaps, number porting, interception and phishing. SP 800-63B-4 still permits them as a restricted authenticator if you offer at least one unrestricted alternative, explain the risk to users and plan a migration. Check signals such as a recent SIM change or port before sending a code. Changing the phone number counts as binding a new authenticator, so it needs authentication at the account's highest level and a notification. A resend must not reset the failure count. ASVS 5.0 drops SMS and phone entirely at level 3, and CISA's December 2024 guidance tells highly targeted people not to use SMS as a second factor.

A WebAuthn credential is scoped to your relying-party ID, and the browser reports the origin it was used on, so a look-alike domain gets nothing it can replay. WebAuthn Level 3 became a W3C Recommendation in August 2026. On each assertion, check the challenge, the origin and the rpIdHash, and require the UV flag when the passkey stands in for both factors. Synced passkeys are copied between a user's devices, so SP 800-63B-4 allows them at AAL2 but not AAL3; the BE and BS flags show whether a credential can be, and is, backed up.

Phishing resistance holds only while nothing weaker remains. Once a user has a passkey, stop offering SMS or email codes at login, require a factor at the same level to add or remove factors, and send lost-device cases through recovery. The passkey guide at /domains/identity-crypto/authentication/passkeys-mfa-lifecycle/ covers registration and verification.

When every factor is strong, recovery is the remaining way in. SP 800-63B-4 sets the floor for saved recovery codes: at least 64 bits from an approved random generator, hashed storage, the same throttling as login, invalidation on use, a replacement code and a notification. Sixteen hex characters shown in four groups carry 64 bits. ASVS 5.0 (6.5.2) requires a salted password hash such as Argon2id for lookup secrets under 112 bits.

A password reset must not switch MFA off (ASVS 5.0 6.4.3): after the emailed link, still ask for the second factor or a recovery code. Replacing a lost factor needs identity proofing as strong as enrollment (6.4.4), and every recovery must notify all the user's addresses. The password reset lab at /labs/recovery/ makes a recovery credential single-use.

Credential stuffing replays username and password pairs leaked from other sites; password spraying tries a few common passwords across many accounts. Both arrive from many IP addresses, so per-IP limits alone miss them, and hard lockouts let anyone lock a victim out. Keep failure counters per account identifier, per client address (an IPv6 host can use its whole /64), per network and overall.

When a counter trips, add friction instead of refusing outright: a bot challenge, a growing delay or risk-based checks, which SP 800-63B-4 lists as ways to avoid locking out the real user. Its hard ceiling is 100 consecutive failures per authenticator. Count failures for identifiers that don't exist, take the client IP only from a proxy header you control (ASVS 5.0 15.3.4), and alert on spikes in failures and in attempts against unknown accounts. Feed the decision with bot signals such as hosting-provider and proxy address ranges, connection fingerprints and headless-browser checks; each can be spoofed, so combine them.

Fixed windows in Redis keep each check to one round trip. EXPIRE NX, available since Redis 7.0, starts the window at the first failure, so later failures don't extend it.

import ipaddress

# (failures allowed, window in seconds) per counter; tune from your own traffic.
LIMITS = {"acct": (10, 900), "ip": (50, 900), "net": (200, 900)}


def counter_keys(account: str, ip: str) -> dict[str, str]:
    addr = ipaddress.ip_address(ip)
    if addr.version == 6 and addr.ipv4_mapped:  # ::ffff:203.0.113.7 from dual-stack sockets
        addr = addr.ipv4_mapped
    host_bits, net_bits = (32, 24) if addr.version == 4 else (64, 48)  # an IPv6 host can use its whole /64
    host = ipaddress.ip_network(f"{addr}/{host_bits}", strict=False)
    net = ipaddress.ip_network(f"{addr}/{net_bits}", strict=False)
    return {"acct": f"fail:acct:{account}", "ip": f"fail:ip:{host}", "net": f"fail:net:{net}"}


def tripped(r, account: str, ip: str) -> list[str]:
    keys = counter_keys(account, ip)
    counts = r.mget([keys[name] for name in LIMITS])
    return [name for name, c in zip(LIMITS, counts) if int(c or 0) >= LIMITS[name][0]]


def record_failure(r, account: str, ip: str) -> None:
    pipe = r.pipeline()
    for name, key in counter_keys(account, ip).items():
        pipe.incr(key)
        pipe.expire(key, LIMITS[name][1], nx=True)  # the window starts at the first failure
    pipe.execute()

SP 800-63B-4 requires checking new passwords against a blocklist of common, expected and compromised values, comparing the whole password and telling the user why it was rejected. It also requires at least 15 characters for a password used alone, or 8 when it is always paired with a second factor, counted in Unicode code points, with no composition rules or forced rotation.

The Pwned Passwords range API checks breaches through k-anonymity: you send the first five hex characters of the password's SHA-1 hash and compare the returned suffixes locally. With the Add-Padding header it also returns dummy rows with a count of 0, so response size doesn't reveal the prefix. The API needs no key and has no rate limit. If it is unreachable, fall back to a local list of common passwords and alert rather than block sign-up; ASVS 5.0 (6.2.4) asks for at least the 3,000 most common at level 1.

import { createHash } from "node:crypto";

// k-anonymity: only the first 5 hex characters of the SHA-1 hash leave the server.
export async function breachCount(password) {
  const hash = createHash("sha1").update(password, "utf8").digest("hex").toUpperCase();
  const res = await fetch(`https://api.pwnedpasswords.com/range/${hash.slice(0, 5)}`, {
    headers: { "Add-Padding": "true", "User-Agent": "example-app-signup" },
    signal: AbortSignal.timeout(3000),
  });
  if (!res.ok) throw new Error(`Pwned Passwords returned HTTP ${res.status}`);
  for (const line of (await res.text()).split("\n")) {
    const [suffix, count] = line.trim().split(":");
    if (suffix === hash.slice(5)) return Number(count); // padding rows carry count 0
  }
  return 0;
}

// Run on registration and password change. Returns a reason to show the user, or null.
export async function rejectPassword(password, { mfaRequired, commonPasswords, log }) {
  password = password.normalize("NFC");
  const length = [...password].length; // code points, as NIST counts them, not UTF-16 units
  if (length < (mfaRequired ? 8 : 15)) return `Use at least ${mfaRequired ? 8 : 15} characters.`;
  if (commonPasswords.has(password.toLowerCase())) return "That password is too common.";
  try {
    if ((await breachCount(password)) > 0) return "That password appears in a known data breach.";
  } catch (err) {
    log.warn({ err }, "breach check unavailable; local list only"); // fail open, but alert
  }
  return null;
}

Attackers enumerate accounts to aim stuffing and spraying, comparing messages, status codes, headers and response times. Return one error for a wrong password, an unknown account and a locked account. When the account doesn't exist, verify against a dummy hash with the same cost, and apply the same throttling. In a test with argon2-cffi defaults, known and unknown accounts answered in 25.8 and 25.7 ms; without the dummy hash, unknown accounts answered in 0.004 ms.

For password reset, queue the lookup and always return the same 202 response. For registration, email the address rather than saying it is taken. ASVS 5.0 (6.3.8) requires this at level 3.

import secrets

from argon2 import PasswordHasher
from argon2.exceptions import InvalidHashError, VerificationError

from limiter import record_failure, tripped

ph = PasswordHasher()                               # Argon2id with the library defaults
DUMMY_HASH = ph.hash(secrets.token_urlsafe(32))     # same cost as a real verifier
FAILED = (401, {"error": "Incorrect email or password."})
SLOW_DOWN = (429, {"error": "Too many attempts. Complete the challenge or try again later."})


def login(users, r, email: str, password: str, ip: str):
    account = email.strip().casefold()              # count every identifier, real or not
    if tripped(r, account, ip):
        return SLOW_DOWN                            # or require a bot challenge first
    user = users.get(account)
    try:
        ph.verify(user["hash"] if user else DUMMY_HASH, password)
        ok = user is not None
    except (VerificationError, InvalidHashError):
        ok = False
    if not ok:
        record_failure(r, account, ip)
        return FAILED
    r.delete(f"fail:acct:{account}")
    return 200, {"next": "second_factor"}           # password alone is not a session


def request_password_reset(queue, email: str):
    queue.put(("send_reset_link", email.strip()))     # the worker looks the account up
    return 202, {"message": "If an account uses that address, we've emailed a reset link."}

Most MFA bypasses are design gaps rather than broken cryptography.

• A half-finished login is not a session: hold the password-verified state on the server and refuse every API call until the second factor passes.
• Mobile APIs, OAuth token endpoints, legacy protocols such as IMAP basic auth and long-lived API keys often skip MFA; give every path the same factors.
• Adding a factor or changing the phone number needs authentication at the account's highest level and a notice to existing addresses (SP 800-63B-4 4.1.2); treat email changes and new API tokens the same way.
• Never log OTPs, push secrets or recovery codes. Compare codes in constant time and accept only ASCII digits; Python's str.isdigit() also accepts superscripts and Arabic-Indic digits.
• 'Remember this device' cookies are bearer credentials: give them an expiry, bind them to the account and revoke them with the user's sessions.
• A session cookie stolen after login bypasses every factor, so keep sessions short and re-authenticate before sensitive actions.

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. NIST SP 800-63B-4 (July 2025), 3.1.3: out-of-band devices, push approval and PSTN rules
2. NIST SP 800-63B-4 (July 2025), 3.2.2: rate limiting (throttling)
3. RFC 6238: TOTP, section 5.2 validation and time-step size. May 2011.
4. OWASP ASVS 5.0.0, V6 Authentication. Version 5.0.0 (May 2025).
5. W3C Web Authentication Level 3: verifying an authentication assertion. W3C Recommendation, 25 August 2026.
6. CISA: Implementing Number Matching in MFA Applications (October 2022)
7. Uber: security update on the September 2022 incident
8. Have I Been Pwned API v3: Pwned Passwords range search and padding
9. OWASP Credential Stuffing Prevention Cheat Sheet
10. OWASP Authentication Cheat Sheet: authentication and error messages

Reference information

Tags

Account takeoverAuthentication and sessionsMFA and passkeys

SDLC phase

Development

Role

DevelopersAppSec engineers

CAPEC attack patterns

• CAPEC-600 at MITRE
• CAPEC-565 at MITRE
• CAPEC-49 at MITRE
• CAPEC-94 at MITRE
• CAPEC-575 at MITRE

Download this guide as Markdown

Continue exploring