After a login-provider breach: scoped resets, session recovery and breached-password screening

Goal

Status as of 25 October 2026. Restore affected users' control after a login-provider breach and reduce password-reuse risk. Re-check the provider's exposure scope, recovery documentation and Pwned Passwords API contract. The reference baseline is NIST SP 800-63B-4, finalized on 31 July 2025; this is not a software patch procedure. Publication record.

Prerequisites

Establish whether the incident exposed your authentication provider, your own password store, or credentials at another service. Process replacement passwords only through systems whose trust has been restored. Have authorized access to authentication logs, session controls and recovery settings. Identify who can reset provider credentials and who can invalidate application sessions; record both as separate tasks.

Steps

1. Scope compulsory resets to evidence. NIST requires a password change when there is evidence that its authenticator was compromised, and rejects routine periodic changes. Identify the affected population from the verified notice and investigation. An unrelated service's breach alone does not establish that every local password was compromised; document the reason for expanding the reset population. Password-verifier requirements.

2. Recover the account, not just its password. Invalidate compromised sessions promptly. Review recovery addresses and multifactor methods with the verified owner and remove unauthorized changes. Do not trust recently changed recovery details alone. Use recovery tokens that expire and work once. After successful recovery, invalidate all existing sessions and outstanding recovery links, and require ordinary sign-in. Preserve accessible support for users who cannot recover automatically. Recovery guidance.

3. Watch for credential stuffing. OWASP defines this as reuse of username/password pairs stolen elsewhere. Review authentication outcomes across accounts and sources, including successful password checks followed by failed multifactor challenges. Monitor each defense's detected and blocked traffic, and investigate suspicious successes. Apply multifactor authentication and layered controls; IP blocking alone is insufficient. Credential-stuffing defenses.

4. Screen newly chosen passwords privately. NIST requires checking prospective passwords against commonly used, expected or compromised values. For the Pwned Passwords lookup, locally compute the SHA-1 hash of the submitted password's UTF-8 bytes, applying the same normalization as your verifier. Send only its first five hexadecimal characters to GET https://api.pwnedpasswords.com/range/{prefix}. Send Add-Padding: true; compare the returned suffixes locally against the rest of the hash. A matching suffix with a positive count is a corpus match; discard padding entries whose count is zero. Reject a matched password, explain why, and require a different choice. No API key is required. Never transmit the full password, full hash or account identifier. Query only after complete entry, not after each keystroke. Range API, NIST screening requirements.

5. Separate screening from storage. SHA-1 is the lookup representation, not the password-storage scheme. Keep salted, costed password hashing as NIST specifies. Perform screening while a new password is available in the normal protected change flow; do not collect existing passwords for a batch audit. The breach corpus supplements checks for common and context-specific choices. NIST requirements.

6. Test before closing the response. With authorized test accounts, verify that old sessions and used recovery tokens fail, legitimate recovery works, and screening handles a positive match, no match, zero-count padding and an unavailable service. Treat lookup failure as unknown, not a clean result. Set an explicit fallback policy, such as a maintained local blocklist, and preserve usability for legitimate users. This is a proposed acceptance checklist.

Expected result

Affected users regain control through verified recovery, exposed sessions no longer authorize access, and newly chosen passwords are screened without sending complete secrets to the lookup service.

Limits and test basis

No application tests were performed for this article. A corpus match identifies a password value, not the user or incident that exposed it; absence from the corpus does not establish safety. Range queries reduce disclosure, not all metadata exposure. Password screening cannot repair a compromised identity provider or replace session recovery. API scope, recovery scope.