Password Breach Monitoring: How SecureLint Detects and Notifies You When Your Credentials Leak

A data breach at a company whose service you use six years ago. A password you stopped using two years ago. A credential stuffing attack on an account you forgot existed. Billions of username-password combinations from historical breaches are freely available on criminal marketplaces, and attackers systematically test them against current accounts. SecureLint's breach monitoring checks your credentials against live breach databases continuously — so you find out about a leak before attackers exploit it.

Why breach monitoring matters for every user

The scale of credential compromise is difficult to comprehend:

• Over 15 billion unique username-password combinations are circulating on criminal forums and dark web marketplaces
• The average time between a breach occurring and the credentials appearing in criminal markets is under 72 hours for high-value breaches
• Password reuse across multiple sites means a single breach of a low-security site can compromise high-security accounts if the same password was reused
• Credential stuffing attacks — automated login attempts using breach data — succeed against roughly 0.1% of tested credentials; at billions of attempts per day, this scales to millions of account takeovers

The only way to know that your credentials have appeared in a breach — and rotate them before attackers exploit them — is continuous breach monitoring.

HaveIBeenPwned k-anonymity integration

SecureLint integrates with HaveIBeenPwned (HIBP), the largest and most maintained public breach database, using the k-anonymity API. This is the same privacy-preserving approach used by major password managers and browsers.

How the k-anonymity check works:

1. SecureLint computes the SHA-1 hash of the password locally in the browser — e.g. 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
2. Only the first 5 characters of that hash (5BAA6) are sent to the HIBP API
3. HIBP returns a list of all breach hashes that start with those 5 characters — typically 500–1,000 entries
4. SecureLint checks whether the full hash of your password appears in the returned list, entirely locally
5. Your actual password or its full hash is never transmitted

When breach checks run

SecureLint performs breach checks at three trigger points:

• Login detection — When SecureLint detects a successful login (a form submission to a known authentication endpoint), it immediately checks the submitted password against HIBP. This provides instant feedback when you use a compromised password to log in.
• Scheduled weekly scan — SecureLint periodically checks all passwords stored in your browser's password manager against the HIBP database. New breaches are added to HIBP continuously, so a password that was clean last week may appear in this week's scan.
• New breach notification — SecureLint subscribes to breach notification feeds. When a major new breach is published, it triggers an immediate out-of-schedule check for all matching credentials.

What the breach notification shows

When a breached password is detected, SecureLint shows a notification with:

• The affected site or service — The domain whose password was found in a breach
• Breach source — Which breach database the credential appeared in (e.g. a named breach, or HIBP count showing how many times this password hash has appeared across all breaches)
• Breach count — How many times this specific password hash has been seen in breach databases — a high count means the password is in widespread criminal circulation
• Urgency level — Low (old breach, password likely already rotated), Medium (recent breach), High (password seen in current credential stuffing campaigns)
• Direct password change link — A link to the affected site's password change page where available

Password reuse detection

Breach monitoring alone is not enough if you reuse the same password across multiple sites. SecureLint also checks for password reuse:

• When a login is detected, SecureLint checks whether the same password is used on any other stored credential
• If a breached password is also used on other sites, SecureLint flags all affected sites — not just the one where the breach occurred
• A password reuse warning appears alongside the breach alert, with a list of all sites using the compromised password

This is the most common vector for breach escalation: a weak password from a low-security forum is reused on a banking or corporate SaaS account, turning a minor breach into a critical one.

Setting up breach monitoring in SecureLint