what-leaked-about-youlisted

# What leaked about you 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. ## What a record actually contains, and what matters 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: | Field | Why it matters | |---|---| | Which service | Membership itself. This person had an account here — a fact you can rarely establish any other way | | Registration date | Time-anchors the identity. Sign-up clusters across services link accounts | | Username in the record | A handle you did not have. Straight into `hunt-a-handle` | | Signup or last-login IP | Coarse geolocation and, more usefully, hosting-vs-residential classification | | Display name, DOB, address | Identity attributes to corroborate elsewhere. Never treat as authoritative | | Password *pattern* | Linkage evidence, analytically. Never an input to a login form | Field-by-field interpretation: [reference/record-fields.md](reference/record-fi