Overview#
When a government HR administrator creates a new platform account, the last thing anyone needs is for that account to be immediately vulnerable because the user recycled a password that appeared in a public breach two years ago. The Security Breach Detection module checks every password against billions of known compromised credentials at the moment of creation or change, and blocks anything that has already been exposed, without ever transmitting the actual password outside the system.
The approach follows NIST SP 800-63B closely: check against known breaches, do not impose arbitrary composition rules that reduce entropy, and do not force periodic expiration that drives users toward predictable patterns. When a password is rejected, users receive clear, specific guidance rather than a vague error message.
Open Standards#
- NIST SP 800-63B (Digital Identity Guidelines): The password policy directly implements this guideline by mandating breach-corpus checks at registration and change, prohibiting arbitrary composition rules, and avoiding forced periodic rotation that degrades effective entropy.
- OWASP Application Security Verification Standard (ASVS) v4, V2.1.7, V2.1.9, V6.2.11: The service enforces these three controls explicitly: V2.1.7 requires rejection of passwords found in breach corpora; V2.1.9 prohibits composition requirements; V6.2.11 mandates a context-aware denylist that blocks passwords containing identity tokens such as email local-parts and tenant names.
- k-Anonymity (Pwned Passwords range-query protocol): The privacy-preserving breach check sends only the first five hexadecimal characters of the password hash to the external corpus, receiving candidate suffixes for local comparison, so the full credential never leaves the service.
- SHA-1 (FIPS 180-4 / RFC 3174): SHA-1 is used solely as the hashing primitive required by the Pwned Passwords range-query protocol; the truncated prefix is transmitted to the breach corpus and the full digest is never stored or used for any security-critical purpose beyond this lookup.
- Argon2id (RFC 9106): Stored password hashes use the Argon2id variant as the primary key-derivation function, with configurable memory, time, and parallelism cost parameters; legacy bcrypt hashes are automatically re-hashed to Argon2id on successful authentication.
- JSON (ECMA-404 / RFC 8259): All breach-check responses from the external corpus API and all internal strength-assessment results are exchanged and returned as JSON, the standard interchange format consumed by downstream authentication and audit pipelines.
Last Reviewed: 2026-02-04 Last Updated: 2026-04-14
Key Features#
- Real-Time Breach Checking: Validates passwords against billions of known compromised credentials during account creation and password changes with no noticeable delay to the user
- Privacy-Preserving Design: Uses k-anonymity protocols so the actual password and its full hash representation never leave the system during the breach check
- Risk-Based Severity Levels: Classifies breach exposure into multiple tiers from informational to critical, with automatic rejection of passwords appearing in large breach corpora
- Comprehensive Password Strength Validation: Evaluates length, complexity, common patterns, and breach status together for a holistic assessment that goes well beyond simple composition rules
- Email Breach Monitoring: Proactively monitors user email addresses against breach databases to enable notifications and password reset recommendations when new exposures surface
- Security Alerts and Notifications: Multi-channel delivery of security events covering new breach exposure detections, repeat exposure warnings, and recommended protective actions
- NIST SP 800-63B Compliance: Breach checking for all passwords, no arbitrary composition rules that reduce effective entropy, and no forced expiration cycles that produce predictable rotation patterns
- Actionable User Guidance: Specific severity messaging with concrete improvement recommendations so users understand exactly why a password was rejected and how to choose something stronger
Use Cases#
- Blocking credential-stuffing vulnerabilities at the source by refusing passwords that already appear in known breach datasets at account creation and every subsequent password change
- Maintaining organisational security posture through continuous monitoring of registered email addresses against newly discovered breaches, with proactive notification to affected users
- Meeting compliance requirements for password security under NIST, ISO 27001, and government IT security frameworks through validated, privacy-respecting breach detection
- Reducing help desk burden by giving users clear, actionable feedback when passwords are rejected, enabling self-service resolution without a support ticket
Integration#
The module connects with the platform authentication system, user management workflows, and notification services to provide seamless breach detection across all password-related operations. Breach check results feed into the audit trail for compliance evidence.