Ramblings of an aging IT geek
← Ramblings of an aging IT geek
news

when the breach wasn't the breach

Reflecting on this month's wave of account-takeover reports and what password reuse and old data dumps mean for how we should actually defend accounts.

A newspaper-style collage of technology headlines

If you've been near a tech feed this June you'll have seen the noise. A string of remote-access and account-takeover reports, users locked out of their own machines or finding sessions they didn't start, and a vendor insisting their systems weren't breached whilst a chorus of affected people insisted otherwise. I'm being deliberately vague on the exact names and numbers because, frankly, two weeks in, the exact names and numbers are still being argued over. The interesting part isn't whodunit. It's the shape of the thing.

the breach behind the breach

Here's the pattern that keeps repeating in 2016, and it repeated again this month. A service gets a wave of account compromises. The service swears blind it wasn't hacked. And the service is probably telling the truth, because it didn't need to be hacked. The credentials were already out there.

We've had an extraordinary run of old breach dumps surfacing this year. The LinkedIn set from 2012 resurfaced in May with a vastly larger count than originally admitted. MySpace, Tumblr, others, all old, all suddenly circulating. Hundreds of millions of email-and-password pairs, many of them years old, all freely available to anyone who wants to try them somewhere new.

And people reuse passwords. That's the whole mechanism. You don't need to breach service B if a meaningful slice of its users handed the same password to service A, and service A leaked it in 2012. The attacker just replays the list. We even have a tidy name for it now: credential stuffing. It is not clever. It does not need to be.

A city skyline at dusk

So when a vendor says "we weren't breached" and the users say "but I was clearly compromised", both can be right at once. The vendor's database held. The users' passwords were borrowed from somewhere else entirely. That nuance gets lost in the headlines, and it matters, because it changes what you should do about it.

what i actually changed

I'll be honest, this month prompted me to do the thing I'd been putting off. I went through my own accounts.

The single highest-value change, by a distance, is a password manager with unique passwords everywhere. I've been running one for a while, but I had a tail of old accounts from before that habit, all sharing a couple of passwords I'd used in my twenties and never rotated. Those are exactly the accounts a credential-stuffing run finds. I generated fresh, unique passwords for the lot and now genuinely could not tell you what any of them are, which is the point.

Second: turn on two-factor authentication everywhere that offers it. A reused password stops being fatal the moment a second factor sits in front of the account, because the leaked credential alone no longer gets anyone in. It's not perfect, SMS-based codes have their own weaknesses, but a TOTP app on your phone is a large step up from nothing and takes ten minutes to set up across your important accounts.

# the practical priority order, roughly:
1. unique password per account (a manager makes this free)
2. 2FA on email first, then anything financial, then everything else
3. stop reusing the password you've had since university

Email first is deliberate. Your email is the skeleton key: it's the reset address for nearly everything else you own. If an attacker gets your inbox, the unique passwords on all your other accounts don't help, because they'll just reset them one by one. Lock the inbox down hardest.

the bit that should worry the vendors

There's a lesson on the other side of this too, for anyone building services rather than just using them. "We weren't breached" is technically a defence and practically useless to your users. If your customers are getting compromised through reused credentials, that's still your support load, your reputation, and your problem, regardless of whose fault the leaked password was.

The defences exist and they aren't exotic in 2016. Check submitted passwords against known-breached lists and refuse the worst of them. Watch for the signature of a stuffing attack, the same handful of source addresses trying thousands of accounts with one attempt each, and rate-limit it. Offer 2FA, and nudge people towards it instead of burying it five menus deep. None of this is novel. The tools to do it are sitting right there.

A busy city street with people

what i take from it

Every few months there's a fresh scare, and the instinct is to treat each one as a new emergency. This month's wave isn't really new. It's the slow tail of breaches that already happened, finding fresh targets through the one habit we can't seem to break, which is using the same password twice.

So the response isn't panic. It's the boring hygiene we all know and mostly don't do: unique passwords, a manager to hold them, and a second factor on the accounts that matter. I finally did the full sweep this week because a headline frightened me into it. The work took an evening. If this month's noise gets you to do the same, then the noise was worth something after all.