Ran into this on a case a few months back and it's stuck with me as one of the more useful low-tech tricks I use now, so figured I'd write it up properly instead of leaving it as a mental note.
The setup: two accounts, no shared email, no shared username, no shared bio text, no shared profile photo. Different platforms entirely. The only reason I even suspected they were the same person was a stylistic tic in how they phrased things. Nothing you'd take to a client on its own.
What ended up connecting them was passwords.
People reuse passwords constantly, and even the ones who don't reuse the exact string tend to reuse a base and mutate it: capitalize the first letter, tack on a year, swap an "o" for a "0", append "!" because some site demanded a special character. If you pull breach records for each identifier separately and look at the raw passwords (plaintext, or cracked hashes where available), those mutations are usually easy to spot once you strip the noise.
Here's roughly how I do it now. Pull every breach hit for each candidate identifier separately, and don't merge them yet, keep them in two buckets. Extract just the passwords from each bucket into a plain list. Normalize by lowercasing everything and stripping trailing digits and symbols, noting what you stripped, so "Blueberry22!" becomes "blueberry" plus a stripped suffix of "22!". Then compare the normalized bases across the two buckets. A shared, unusual base string is a real signal. A shared common one, "password", "qwerty123", "iloveyou", is basically noise, ignore it. If you get a hit, go looking for a second, independent signal before treating it as anything more than a lead: a secondary recovery email buried in one of the records, a phone number, a registration pattern, anything that isn't also derived from the password match itself.
Worked example, details changed since it's from real casework: one identity had a leaked password of "TeddyBear19," the other had "teddybear_2019!!" on a completely different platform. Normalized, both reduce to "teddybear." Not proof by itself, plenty of people like teddy bears. What made it a real lead was one of the two dumps also having a partially masked recovery number ending in the same four digits as a number already tied to the first identity from earlier in the investigation. The password match is what got me looking there in the first place.
A few things worth knowing before you rely on this. Weak, common passwords will burn you. If the shared base is something like "sunshine" or "monkey123," you'll get false positive after false positive. The signal gets stronger the weirder and more personal the base password is: inside jokes, pet names, misspellings, anything that isn't in the top 10,000 list. It's also getting less reliable every year as password managers spread, and that's a good thing. If someone's been using randomly generated passwords since 2021, this technique won't produce anything for them, no shared base to find. Don't force it.
And obviously, this only makes sense where you already have a legitimate reason to be linking these identities: an authorized investigation, your own accounts, a security assessment you're actually cleared to do. It's a correlation technique, not a magic trick, and it's exactly the kind of "lead, not evidence" thing that gets people in trouble when they skip the corroboration step.
Doing this by hand across five separate breach-search tabs got old fast, so I ended up scripting the normalize-and-compare part for myself. Not turning this into a plug, the manual version above works fine on its own if you'd rather do it that way.
