When a user submits a password change through the settings panel, the candidate password is validated against the Have I Been Pwned breached-password dataset before the change is written. The check uses the HIBP k-anonymity range API: only the first five characters of the SHA-1 hash of the candidate password are sent to the external service, and the server matches the response locally against the full hash — the plaintext and the complete hash never leave the platform.
How the check works
- Hash prefix query. The platform computes the SHA-1 hash of the candidate password, takes the first five hex characters, and queries the HIBP range endpoint. The endpoint returns all hash suffixes that share the prefix along with their breach occurrence counts.
- Client-side match. The platform compares the remaining hash characters against the returned suffix list. A match with a non-zero occurrence count causes the change to be rejected with a user-facing message.
- Blocking before commit. The check runs in the password-change handler before the new hash is written to the credential store; a breached password is never persisted even transiently.
The check applies to user-initiated password changes through the settings panel. It complements existing strength and complexity rules: a password that passes complexity requirements can still be rejected if it appears in a breach dataset.