Breach data answers a question nothing else answers cheaply: which services did this identity actually use. That service list is almost always worth more to an investigator than the credentials in the record — and the credentials are the part you must never touch. Using a leaked password is unauthorized access, no matter how public the dump was.

A breach record is a row from a service's user table. Typical fields: email, username, a password hash (or plaintext, in bad cases), registration date, last login, IP address at signup, display name, date of birth, physical address, security questions, and whatever the service happened to collect.

The metadata beats the credentials, every time:

hunt-a-handle

Field-by-field interpretation: reference/record-fields.md.

find-leaks-in-the-wild

Have I Been Pwned is the default starting point. It is curated: breaches are verified before loading and data classes are labelled, so a hit means something. Free web lookup for an email; the API is keyed and permits programmatic and domain-wide checks. It deliberately does not hand you passwords.

Pwned Passwords is worth understanding properly because the design is the point. You SHA-1 the password locally, send only the first five hex characters of the hash to the range endpoint, and receive every hash suffix sharing that prefix, with occurrence counts. You match locally. The service never learns which password you asked about. This makes it safe to run against credentials you legitimately hold, and it is the correct tool for a self-audit or a client remediation exercise.

Keyed commercial services — DeHashed, IntelX, and Snusbase are the commonly used ones. What differentiates them:

Access model and coverage comparison: reference/source-catalogue.md.

Never use a leaked credential to authenticate to anything. Not to "confirm the account exists". Not on a test account. Not on the subject's account with a client's verbal blessing. Credential stuffing is unauthorized access under computer-misuse law in most jurisdictions, and the public availability of the password is not a defence — see ../../ETHICS.md.

The same applies to derived actions: do not attempt password resets, do not use recovered security-question answers, and do not try a recovered password on a different service to test reuse. Reuse is something you infer from data you already hold, never something you test.

Work the breach list as an account map. An email appearing in a gaming forum, a fitness app, and a regional dating service tells you three platforms to investigate, three registration dates, and often three usernames — each one a seed for . The services themselves characterise the person: professional, regional, linguistic, and interest signals that no profile page would give you.

Password patterns are linkage evidence when handled correctly. If two records under different identities carry the same distinctive password — a long, non-dictionary, clearly personal string — that is meaningful correlation, and you record it as an analytic observation with the string itself redacted or hashed in your notes. A common password (, a keyboard walk, a football team) links nothing; thousands of people share it. Distinctiveness is the whole signal, and the evidence is the coincidence, not the credential.

Records commonly contain hashes: MD5 or unsalted SHA-1 on old breaches, salted schemes and purpose-built password hashes on newer ones. You will occasionally see plaintext where a service stored it unhashed, and reversible encryption where someone chose badly.

Note the hash type — it dates the breach and characterises the service's security posture, which is genuinely useful in a due-diligence context. Then stop. Cracking a hash produces a credential you are not allowed to use, so the work has no legitimate output. The exception is a self-audit or an authorized security assessment where the password holder is your client, and even then the range API answers the question without cracking anything.

Grade the breach, not just the record. A well-attributed breach makes every row in it more credible; an anonymous compilation makes every row less so.

Self-audit for a client using . HIBP returns four breaches. One is a large forum breach from several years back, data classes listed as email addresses, usernames, IP addresses, and password hashes.

The username in that breach is , which the client had forgotten using. That handle goes to and turns up two live accounts the client did not know were still public — the most valuable output of the exercise and nothing to do with credentials.

The dead end: a commercial source returns a fifth "breach" attributed to a retailer, containing a home address. The retailer has never disclosed an incident, the field layout does not resemble a retail order table, and the same address appears in two data-broker records. Assessed as scraped aggregator data relabelled as a breach. Excluded from the report with the reasoning recorded.

Remediation: passwords the client still uses are checked through the Pwned Passwords range API, so no password leaves the machine. No credential from any record is used anywhere.

Holding breach data is regulated, and more tightly than most OSINT material. Under GDPR and UK data protection law, breach records are personal data — often special-category data — and processing them needs a lawful basis, a defined retention period, and demonstrable data minimisation. Some jurisdictions treat possession of certain stolen data as an offence in itself, irrespective of how you obtained it. Several commercial services restrict their data by licence to specific purposes; read the terms before you put results in a client report.

Practically: pull the minimum fields needed for the objective, do not retain credentials at all, store case material encrypted at rest with access logged, and delete on a schedule you wrote down at the start. If you are working for a subject on their own data, that is the cleanest footing available — and it is the only footing on which testing a password is ever appropriate.