Password Managers, From Someone Who Reads Breach Dumps

A breach dump is a boring file. That’s the first thing nobody tells you.

Rows of text. An email address, a colon, a password. Sometimes a name and a phone number tagging along. Ten million rows, then another file, then another. I’ve been reading them for years, because keeping XposedOrNot’s catalog honest means looking at what’s actually in there rather than what the headlines say.

And after enough of them, you stop noticing the passwords and start noticing the patterns. So this is what the files taught me, with the numbers from our own catalog as I write this: 783 breaches, 516 of which leaked passwords. Then an argument with the sceptic in my head. Then the paragraph you can paste to your family.

The same password, in seven places

The files that scare me most aren’t breaches. They’re combolists.

A combolist is someone else’s homework: email and password pairs lifted from dozens of older breaches, deduplicated, and stitched into one file so an attacker can try them everywhere at once. Our catalog holds four of them that leaked passwords. Collection-1 alone is 790,803,860 records. Together the four run to 1.43 billion.

Why would anyone bother assembling that? Because it works. It works because the password you used on a forum in 2016 is, more often than any of us would like, the password on your email today.

That’s the whole business model, in one file.

What travels with the password

A password on its own is a curiosity. A password next to the right other fields is a key.

Of the 516 password-leaking breaches, every single one also lists email addresses. That’s the pair a combolist needs. 329 of them, 64%, throw in usernames as well, which makes the pair portable to sites that log in by handle rather than email. 231 include IP addresses. 187 include names. 111 include dates of birth, which is still a security question at plenty of banks.

So when I say “your password leaked”, picture the row, not the word. The row has your email, probably your username, sometimes your birthday. That’s a login attempt and a password-reset attempt sitting side by side.

More than half the time, the lock was decorative

I counted this one properly in yesterday’s storage post. Of the 516 breaches that leaked passwords, 289 stored them in plaintext or with hashing you can crack on a gaming PC. Fifty-six percent, and that’s the floor.

Put another way: 6.75 billion records sit inside password-leaking breaches in our index, and 5.26 billion of those sit inside the badly stored ones. (Records, not people. One person is in many of them. Still.)

You picked a good password. The company on the other end kept it in a spreadsheet. Nothing you did changed that outcome, and nothing you can do will.

The bigger the breach, the worse the lock

This one surprised me, and I’ve had the data for years.

Sort the 516 by size and look at how many in each band stored passwords recoverably. Small breaches, under 100,000 records: 45%. Everything from there up to 100 million: somewhere between 55 and 57%, and boringly steady about it. Then you get to the fourteen breaches over 100 million records, and thirteen of them kept passwords in plaintext or behind hashing a hobbyist could crack. Ninety-three percent.

Partly that’s combolists and stealer logs, which are plaintext by nature and huge by design. But take those out and it barely moves: ten ordinary breaches in the catalog top 100 million records, and nine of them stored passwords recoverably. Meanwhile the ten largest password-leaking files of any kind hold 3.36 billion records between them, almost exactly half of everything password-related we index, and nine of those were recoverable too.

The scale of a breach tells you nothing about the care behind it. If anything it runs the other way.

Who stored them badly

The catalog tags each breach with an industry, so I asked which ones were worst.

Entertainment sites (games, streaming, forums, the places you sign up to on a whim) are the biggest group, 187 of the 516, and 64% of them stored passwords recoverably. Information technology companies, who really ought to know better, are next at 65%. Retail is the surprise in the other direction, under a third, and finance is about the same on a group of only sixteen.

Small groups swing easily, so hold the finance number loosely. But the shape is clear enough. The accounts you care least about are the ones most likely to have kept your password in the clear. And if that password is also the one on the account you care most about, well. That’s the reuse maths again.

It hasn’t stopped

I’d love to write that this was a 2016 problem. 2016 was the worst year for password leaks in the catalog, as it happens: 66 breaches, 1.43 billion records, 49 of them stored badly. But the catalog says it’s still going.

So far in 2026 we’ve added 31 breaches that leaked passwords. Between them, 403,097,613 records. One of the 31 is a stealer log, and on its own it’s 299,646,818 addresses. Every password in it was grabbed as typed. Not hashed, not encrypted, typed. That’s what infostealer malware does for a living. (Stealer logs are their own animal; the three-leak taxonomy explains the difference in plain words.)

New rows, every week. Old passwords, most of them.

You find out late, and later if it was stored badly

One relation I’d never checked before this post. Take every password-leaking breach and measure the gap between the date it happened and the date it reached our catalog. The median is 2,122 days. Nearly six years, and well past the four-year figure for the catalog as a whole. Password breaches surface later than the rest.

Now split by storage. Breaches that hashed passwords properly reached us after a median 1,376 days. Plaintext breaches took 2,624. Weakly hashed ones, 2,686.

I won’t over-read that.

Old breaches skew plaintext because everyone stored passwords badly in 2012, and old breaches surface late because that’s how old breaches work. But the practical point survives the caveat: the passwords most worth stealing are the ones you’ll hear about last. By the time the alert lands, the breach itself is years old.

The only number you control is one

Here’s the reuse maths I promised yesterday, and it’s short.

A recovered password is a fact. You can’t undo it. What it costs you, though, is entirely down to how many places it opens. One account, if the password was unique. Every account you own, if it wasn’t.

So the question was never “how do I stop companies losing my password?” You can’t. The question is “how many doors does one lost password open?” And the only honest way to make that answer “one” for the 150-odd accounts most of us have collected is to stop being the thing that remembers them.

That’s a password manager. Software that makes unique-everywhere the default instead of a discipline. Everything else people say about them is detail.

The argument with the sceptic

I have this conversation a lot. Usually with myself.

“So you want me to put every password in one place. Isn’t that a single point of failure?”

Yes. It is, and I’d be lying if I said otherwise, because it’s already happened once at scale. In 2022 one of the big names in password managers got breached. The attackers walked off with encrypted customer vaults, about the worst headline that whole product category can get. What decided who was fine? The master passphrase, and almost nothing else. Anyone with a long one kept their passwords behind the encryption. Anyone with a short one had, quite reasonably, a bad few months.

So the vault doesn’t remove risk. It squashes all of it into two things you control: a long passphrase and two-factor on the vault. Compare that with the alternative, which is being exposed to every breach at every site where you reused a password, at 56% recoverable odds, for the rest of your life. Concentrated and fixable versus spread everywhere and fixable by nobody. I’ll take the first. I did, years ago.

“Fine. Which one?”

Whichever one you’ll actually open. I don’t do affiliate links, so this is the unmonetised answer and it’s a boring one: the gap between the well-known managers is tiny next to the gap between using one and not using one. The one built into your browser already beats reuse. A standalone app beats that, mostly because it survives you switching browsers or dropping your phone in a lake, and it’ll hold your passport number and the wifi password too.

Four things I’d look at before committing, none of them exciting. Whether the provider can read your vault, which they shouldn’t be able to, and the phrase to look for is end-to-end encryption. Whether two-factor covers the vault login itself. Whether you can export everything and walk away. And if they’ve had an incident, whether they said so plainly or you found out from a journalist.

“I’ll just remember them.”

No. You’ll hold three passwords with the year on the end changed, like everyone else, and I’ve read the file that proves it.

“Then why do I keep hearing about people getting hacked anyway?”

Because reuse is the biggest hole, not the only one. Phishing still lands. Malware on the laptop still hoovers up whatever you type (that stealer log again). What a manager buys you is that one lost password costs one account and nothing more. It won’t make you unphishable. Someone tells you it will? Ask what they’re selling.

The 30-minute start

Whatever you do, don’t try to move all 150 accounts in one go. I’ve watched people try. That’s how this dies on a Sunday afternoon with the kettle on and forty tabs open.

First ten minutes. Install it, then invent your master passphrase: long, memorable, and (this is the nice part) the last password you’ll ever have to make up. Two-factor on for the vault, and you’re done with setup.

Next fifteen. Email and banking, nothing else. New unique passwords for both. Email goes first because it resets everything else, and because, as the numbers above show, it sits next to the password in every one of the 516.

Last five. Find out what’s already out there. Run your address through XposedOrNot (ten seconds, no signup) and any account whose password has already leaked jumps the queue. Wondering if an old favourite is among the 835,955,029 passwords we’ve seen exposed? Try it in the password checker. It never leaves your browser: the page hashes it locally and sends the first ten characters of the hash, nothing else. And if you loved that password, I promise you weren’t alone.

Everything else migrates lazily. Each time you log in somewhere old, let the manager capture it, and if it was a reused one, replace it there and then. Three months on, the problem has quietly solved itself.

Then switch on the free breach alert so the next leak comes to you. Given the six-year median above, it’ll probably be an old one. Password hygiene isn’t a project. It’s a default plus a notification.

The paragraph for your family group chat

Use a password manager. Not because you’re careless, but because companies lose passwords all the time, more than half the time in a form attackers can read, and the only defence you fully control is making every password unique. Long master passphrase, two-factor on the vault, email and bank first, the rest lazily. Ten-second check for what’s already leaked, free: xposedornot.com

That paragraph’s yours. Paste it wherever it helps.

Devanand Premkumar, founder, XposedOrNot

Frequently asked questions

Is a password manager safe if the company gets breached? Mostly. The 2022 incident sorted people into two groups, and the sorting hat was the master passphrase. Long one: the thieves had a file they couldn’t open. Short one: trouble. Two-factor guards your account’s front door, not a stolen file, so have both anyway. Even on a bad day, though, I’d rather be that person than the one whose single reused password is sitting in a dozen breaches they’ll never hear about.

How do I check a password without giving it away? Go to xposedornot.com/password and type it in. Your browser hashes it on your side and sends us the first ten characters of that hash, nothing more. We match that fragment against 835,955,029 exposed passwords. The password itself never leaves your machine.

Appendix: sources and references

• Catalog figures, all pulled from api.xposedornot.com/v1/breaches on 7 September 2026, script below: 783 breaches; 516 leaking passwords; 289 recoverable; 6,750,022,029 records in password-leaking breaches, 5,259,318,558 in the recoverable ones; four password-leaking combolists totalling 1,433,283,890; 31 password-leaking breaches added in 2026 with 403,097,613 records; AlienStealerLogs 299,646,818; co-exposed types (email 516, usernames 329, IP addresses 231, names 187, dates of birth 111); recoverable share by size bucket (45% under 100k, 57% 100k to 1M, 55% 1M to 10M, 56% 10M to 100M, 93% over 100M); ten largest password-leaking breaches hold 3,363,239,734 records, nine recoverable; ten DataBreach-type entries at or above 100 million records, nine recoverable; industry counts (Entertainment 120 of 187, Information Technology 62 of 96, Retail 16 of 53, Finance 5 of 16); 2016 = 66 breaches, 1,428,032,360 records, 49 recoverable; median breach-to-index lag 2,122 days overall, 2,624 plaintext, 2,686 weak hashing, 1,376 strong hashing.
• Storage classification method and the 56% figure: blog.xposedornot.com/password-storage-analysis-2026/, 7 September 2026.
• Password checker figure (835,955,029 exposed passwords) and the local-hash, ten-character-prefix method: xposedornot.com/password, read 7 September 2026.
• The 2022 password-manager breach: the vendor’s own security-incident disclosures, 22 December 2022 and 1 March 2023.

Reproduce the catalog numbers

import json, urllib.request, collections, statistics, datetime
req = urllib.request.Request("https://api.xposedornot.com/v1/breaches", headers={"User-Agent": "Mozilla/5.0"})
d = json.load(urllib.request.urlopen(req))["exposedBreaches"]
pw = [x for x in d if "Passwords" in x["exposedData"]]
bad = [x for x in pw if x["passwordRisk"] in ("plaintext", "easytocrack")]
print("password-leaking:", len(pw), "records:", sum(x["exposedRecords"] for x in pw))
print("recoverable:", len(bad), "records:", sum(x["exposedRecords"] for x in bad))
print("co-exposed:", collections.Counter(t for x in pw for t in x["exposedData"] if t != "Passwords").most_common(5))
for lo, hi, lab in [(0, 1e5, "<100k"), (1e5, 1e6, "100k-1M"), (1e6, 1e7, "1M-10M"), (1e7, 1e8, "10M-100M"), (1e8, 1e13, ">100M")]:
    g = [x for x in pw if lo <= x["exposedRecords"] < hi]
    print(lab, len(g), sum(x in bad for x in g))
ind = collections.Counter(x.get("industry") for x in pw)
print("industry:", [(k, ind[k], sum(x in bad for x in pw if x.get("industry") == k)) for k, _ in ind.most_common(4)])
def lag(x):
    a = datetime.datetime.fromisoformat(x["addedDate"].replace("Z", "+00:00")).replace(tzinfo=None)
    b = datetime.datetime.fromisoformat(x["breachedDate"].replace("Z", "+00:00")).replace(tzinfo=None)
    return (a - b).days
print("overall median lag:", statistics.median(lag(x) for x in pw))
for lab, risk in [("plaintext", "plaintext"), ("weak", "easytocrack"), ("strong", "hardtocrack")]:
    print(lab, "median lag days:", statistics.median(lag(x) for x in pw if x["passwordRisk"] == risk))
top = sorted(pw, key=lambda x: -x["exposedRecords"])[:10]
print("top10:", sum(x["exposedRecords"] for x in top), sum(x in bad for x in top))
big = [x for x in pw if x["exposedRecords"] >= 1e8 and x["breachType"] == "DataBreach"]
print("ordinary >=100M:", len(big), sum(x in bad for x in big))
y = [x for x in pw if x["breachedDate"].startswith("2016")]
print("2016:", len(y), sum(x["exposedRecords"] for x in y), sum(x in bad for x in y))
print("finance:", ind["Finance"], sum(x in bad for x in pw if x.get("industry") == "Finance"))
print("added 2026:", len([x for x in pw if x["addedDate"].startswith("2026")]))

Output on 7 September 2026: password-leaking 516, records 6750022029; recoverable 289, records 5259318558; co-exposed Email addresses 516, Usernames 329, IP addresses 231, Names 187, Dates of birth 111; buckets <100k 60/27, 100k-1M 194/111, 1M-10M 177/98, 10M-100M 71/40, >100M 14/13; industry Entertainment 187/120, Information Technology 96/62, Miscellaneous 62/29, Retail 53/16; overall median lag 2122; plaintext 2624, weak 2686, strong 1376; top10 3363239734 / 9; ordinary >=100M 10 / 9; 2016: 66 / 1428032360 / 49; finance 16 / 5; added 2026: 31.

—