The breach that leaks your data isn’t yours to prevent

Data breaches kept landing through the first weeks of 2021, and the biggest item of the month wasn’t even a new one. A file called COMB, the Compilation of Many Breaches, went up on a public forum in early February. CyberNews counted more than 3.2 billion email and password pairs in it once duplicates were removed, credentials exposed in earlier leaks and gathered into one archive with scripts for counting and searching them (CyberNews). Which databases fed it is not settled: CyberNews says it isn’t clear which previously leaked databases the file contains, and names like Netflix ride along in it without a known breach behind them. The shape of the thing is clear enough anyway. Billions of credentials people handed to a service are now in one searchable archive, and getting there was never the account owner’s decision.

That’s the uncomfortable part. You can pick a good password and turn on a second factor, and none of it touches the database at the other end. You gave someone a real postal address because you wanted the package delivered, and a real email because the receipt had to arrive somewhere. When that company gets hacked, your data gets sold back to them as ransomware or dumped on a forum. Marketing firms buy it. Other people turn it into phishing mail that looks convincing because it quotes a real order.

So the question isn’t how to avoid breaches. It’s what the next one costs you: which account it opens, what else that account unlocks, how long before you notice, and how fast you can cut the leaked identifier off. A listener asked us how we set up our own machines and handle client data, which is the same question seen from the work end. Both answers start in the same place, with deciding what is actually worth defending.

Decide what you’re protecting before you buy anything

Security at work starts with a risk analysis, and there’s no reason your own setup should skip that step.

What should you protect first?

The handful of accounts that unlock everything else: your email, your password manager, your cloud storage. Those are the crown jewels. Plenty of other accounts can leak without the damage being serious, and treating them all as equal is how people burn their energy in the wrong place.

The threats worth planning around in early 2021 are narrow enough to list. Phishing aimed at card data, so someone can cash it out. Credential stuffing, which is what a file like COMB is for: take an address and a password from one dump, replay them against a hundred other services. Ransomware, which for individuals is less common than it was, because the gangs worked out that a company with cyber insurance pays far more than a person with a laptop.

Then be honest about where the ceiling is. We store backups with online providers, but everything that goes up is already inside a VeraCrypt container, so a breach at the provider hands someone an encrypted blob. That stops an opportunistic attacker. If someone serious with real resources is after you specifically, you’re in trouble anyway. Building for that case is how you end up in the forest with a tinfoil hat and no running water.

Give every service its own email address

The thing you leave behind everywhere, at every service, in every breach, is your email address. It’s the join key an attacker uses to connect one dump to the next.

What does a separate address per service buy you?

Attribution, and an off switch. The address only one company ever had is the address that tells you which company leaked, and it’s the one you can block without breaking anything else.

Buy a domain and pay for a mailbox on it. Paying matters. If your whole life hangs off one free address and that account goes away, you’re in deep trouble, and a provider you pay has a monetization model you can at least read. ProtonMail and Tutanota both take a custom domain, and both let you point a catch-all at it, so anything @yourdomain lands in your inbox however you spelled it. Then invent a fresh address for every signup. The pattern we use is the service name followed by ten random characters from random.org, so seeing one address gives nobody the one you gave another service.

There’s a cheaper version that buys the attribution and none of the protection. Gmail ignores anything after a + in the local part, an address variation documented since 2008 (Gmail blog), so you+zencastr@gmail.com reaches your inbox and the mail that turns up at it names the service that sold you out. The limitation is the + sitting right there in the string. Strip the suffix and whoever bought the list has your real address, and padding that suffix with random characters doesn’t change it. A plus-address tells you who leaked without hiding anything.

The same trick works on the other identifiers, with more friction. A phone number proxied through Twilio, a one-time card number instead of your real one. Both put a third party in the middle of your data and both cost money.

Unique passwords, a second factor, and a way back in

Per-service addresses only pay off if the password behind each one is also unique, which rules out remembering them.

How many random passwords can a person actually keep?

Far fewer than you need, so use a password manager for every account, no exceptions. One of our managers currently holds 559 entries, and keeping 559 unique random strings in your head isn’t practical. That’s not discipline, it’s a tool doing the remembering.

The standard here is written for the service, not for you. NIST SP 800-63B tells verifiers to compare new passwords against lists of known compromised values and to support a maximum password length of at least 64 characters. It also tells them to drop composition rules and forced periodic rotation, because those push people straight back into reuse. None of that is yours to implement, and from the outside you can’t tell whether a given site does any of it. What you control is the string you hand over, and a generated random one per service is the strongest version of that.

Put a second factor on top wherever the service offers one, whether that’s a one-time password app or a hardware key. A password plus one hardware key is already two factors: something you know and something you have. The reason to buy two keys isn’t that one key authenticates weakly. It’s that the second one is your way back in.

Register the spare before you need it, because a key is not something you can copy afterwards. Yubico’s firmware doesn’t let a secret be read back off the device once it has been written, so its own advice is to keep a second device and register both with your accounts (Yubico). The exception is a credential you saved at the time you programmed it: with OATH-TOTP you can write the same shared secret onto a second key later, as long as you kept the secret or the QR code it came from. Without it, the route to a matching pair is to delete the credential at the service and enrol both keys again. Keep a second method anyway, since a key you can’t plug into your phone is a key you can’t use when you’re away from your desk.

Plan for losing the key, and for losing the provider

Some services let customer support reset authentication, making their recovery process another route into the account.

Which control is really protecting the account?

The weakest path back into it. On a large retail account you can enrol a hardware key and still be let back in after answering a few simple questions on the phone. The account’s real strength is the quality of those questions.

Lose your only key and there’s nothing to recover unless you still have access to the account, so the way back in is to write to customer service, and quite often they will sort it out for you. That is the problem as much as the remedy: the recovery desk is a vector, open to anyone willing to claim they are you. Our own run-in with it makes the point. Cancelling one unused account took so much back and forth and so many scanned documents that it felt absurd. Then the reason for it landed. Without that friction, someone could call in, say they had lost the account and walk out with the data in it. Painful recovery is the control.

The other way to lose an account is for the provider to stop being available to you. Social login makes that worse, which is why we register with an email address when the option exists rather than signing in with Facebook or Google. Apple’s version at least includes a relay address instead of your real one (Sign in with Apple). It still hands one vendor the keys to everything, and vendors become unavailable: an outage, an account closure, a country ending up on the wrong side of a sanctions regime. Do the exercise deliberately. We export the password manager every quarter into an encrypted container, not because 1Password is likely to vanish, but because the recovery path should exist before it’s needed.

Encrypt before you upload, and keep backups ransomware can’t reach

Storage is the part people assume is solved, and there is no shortage of companies willing to hold yours for free or close to it.

What happens to your files when the storage provider gets breached?

Files you uploaded in the clear can be exposed, depending on what the intruders reached: the systems that serve file contents, the keys the provider holds on your behalf, or an account with permission to read them. Which of your files that covers is the provider’s to work out and yours to live with, and you learn the answer after the fact.

So encrypt it first, with a key that stays on your side. Our cloud backups are VeraCrypt containers, uploaded already encrypted, so a breach at the provider hands over a file nobody there holds the key to. It isn’t elegant, and it doesn’t help against a targeted attacker who can reach your machine. It takes a whole class of bad day off the table.

The other half is ransomware, and the answer is unglamorous. We watched a demand land in 2017, in Bitcoin, not a small amount, and it was not fun even with backups in place. The backups are what made restoring an option instead of negotiating. The pitch we keep hearing at conferences is the other way round: hire someone to hunt down the people who encrypted your data and recover the key. Buy the extra storage instead.

Coveware’s Q4 2020 figures put the average ransom payment at $154,108. Among companies also threatened with publication of their stolen data, the share that paid fell from 74.8% in Q3 to 59.6% in Q4. Coveware puts that down mainly to eroding trust that payment keeps the data offline, with restoring from backup as the alternative on the table. Those publication threats are the growing half of the problem, up from 50% of attacks in Q3 to 70% in Q4, and that is the half a backup does nothing about.

Phishing is the route that keeps working

Backups cover the aftermath. In the ransomware cases Coveware worked in Q4 2020, email phishing overtook RDP compromise as the dominant attack vector.

What does a modern phishing attempt look like?

Ordinary. The one that gets people now is junk mail for a subscription you don’t remember, with the malicious link planted in the unsubscribe button. That button is the thing an annoyed reader is most likely to click.

It is one route in rather than the only one. RDP compromise stayed very common through the same quarter, and the breach later in this piece started with a stolen laptop; how the attackers got from there into the owner’s email was never established.

The older lures are cruder and still work. A mail asks whether your card has been stolen, with a form for the number so it can be checked. Then comes the follow-up for the expiry date and the CVV. The tell isn’t the question, it’s who is asking. Have I Been Pwned answers the legitimate version of it from an email address alone. Its password search sends only the first five characters of a SHA-1 hash, so the password itself never leaves your machine (Troy Hunt).

Verify out of band when something feels urgent. A PDF from your boss that needs opening right now deserves a phone call, an SMS, any channel other than the one the message arrived on. Here’s why the urgency matters, from the trenches: a water company lost one user to a phishing campaign, and the attackers changed the password first. The account’s owner was locked out while the attackers sent phishing messages from that account. Everyone who replied was replying to them. The owner was stuck with the support desk trying to get the account back, and the messages kept going out in the meantime.

Treat the work laptop as something you’ll lose

Not every route in starts with a click. Laptops get stolen, and what sits on them goes with them.

What does an attacker read first on a stolen laptop?

The downloads folder, then your home directory. ~/Downloads accumulates every document you ever opened and nobody cleans it, and the dotfiles hold the credentials: ~/.ssh keys, config files with tokens in them.

So keep that surface small on purpose. Full disk encryption first, every machine, every time: FileVault on a Mac, the equivalent elsewhere, and enable Find My Mac so a lost machine can be wiped remotely. If you see a checkbox offering encryption, tick it. Our own setup runs a separate virtual machine per customer, each one encrypted, backed up to S3 as an encrypted image and deleted when the engagement ends. The host itself carries a short standard list of software, so a replacement Mac gets back to work quickly. There are no SSH keys sitting on it, and AWS access goes through aws-vault against AWS SSO, so what lands on disk is a short-lived session rather than a key.

We were close to a breach in 2019 that started with a stolen developer laptop. The attackers ended up inside the victim’s email, and how they got there we never established. From the mailbox came password resets, and from the resets the company’s shared drive. Departmental segregation is the reason the financial data stayed out of it. For a listed company, a financial-data leak could have made the consequences much worse: a huge drop in the stock, and bankruptcy on the table. The fix afterwards was forced reauthentication on a 24 hour window. It’s irritating, and it beats an open mailbox that has been sitting unlocked since last Tuesday.

A secret in a chat channel is a secret in an archive

The same logic applies to the places your team talks, because that’s where credentials get pasted when someone is in a hurry.

What should you do after pasting a token into Slack?

Rotate it immediately. Treat anything posted in chat as compromised from the moment it lands, because it is now in an archive that anyone holding that account’s session can search, for as long as your workspace’s retention settings keep messages around.

Chat feels safer than email, and in an internal-only channel it partly is: the members are accounts your own workspace issued, behind a login, a password and a second factor. How far that holds is a configuration question rather than a property of the tool. Slack Connect already lets a channel reach people at other organisations, so whether anyone outside yours sits in one depends on what your admins allow. Either way, enclosed is not isolated. One compromised endpoint, one phone, and the attacker gets a search box over the retained messages that account can reach, which for a private channel means the ones it was a member of. Secrets stay out of it. Share them through the password manager. Or encrypt them with something built for the job, such as Vault’s transit engine, which encrypts under a named key and doesn’t store the data it encrypts. Be clear about what that does and doesn’t give you: the ciphertext isn’t bound to a recipient, and whoever holds a Vault policy granting decrypt on that key can read it. For a one-off share, the password manager is the simpler answer.

The Twitter takeover of July 2020 is the example we reach for, and it’s worth getting the record right. Our recollection on air was that credentials shared in Slack were the way in. The New York regulator’s investigation describes something plainer: phone calls in which the attackers posed as Twitter’s IT department, with “no malware, no exploits, and no backdoors” (NYDFS Twitter Investigation Report, October 2020). The attackers took $118,000 in Bitcoin. The Slack detail is second-hand and doesn’t appear in the report at all: it comes from Joseph O’Connor, one of the people interviewed for the original reporting, relaying what other hackers had told him about credentials posted in Twitter’s internal Slack (New York Times, syndicated here, July 2020). The habit is worth keeping regardless, because the rest of the story is a reminder of how little sophistication the job took.

What this means for teams

The useful reframe comes from a tweet that puts the questions in the wrong order on purpose (@eey0re). Most teams start at “how should I protect this data?”. That’s the third question. The second is “should I collect this at all?”. The first is: what would the worst possible people do with it if they got hold of it? Answer that one first and a surprising amount of the data you were about to store turns out not to be worth storing. Data you never collected can’t leak, and it needs no encryption, no retention policy and no breach notification.

Four things worth doing this week:

• Put a catch-all on a domain you control and start migrating signups to per-service addresses, highest value accounts first.
• Enrol a spare second factor on the accounts that would hurt most, and write down what you’d actually do if the primary one vanished tonight.
• Check that one of your backups is both current and out of reach of a machine that gets encrypted, then restore a file from it to prove the restore path works.
• Clear ~/Downloads, audit what credentials are sitting in your home directory in plaintext, and move them behind a manager or a session broker.

Common questions, answered

How do I stop the spam after a company leaks my email address?

Block the address they leaked, which only works if you gave that company an address of its own. With a catch-all on your own domain you kill one alias in a filter, change the address at that one service and the spam stops, while everything else keeps working.

With a single shared address there’s no equivalent move. You can filter on sender, but the list grows faster than you can maintain it, and the address is now in a compilation that gets replayed against new services for years.

What happens if I lose my YubiKey?

Use the spare you registered, which is why the standard advice is to set one up while you still have access to the account. Without one, you’re left with whatever backup method the service offers: a one-time password app, recovery codes, or a support desk that asks you some questions.

That last option is worth noticing. If a phone call can restore access to an account protected by a hardware key, the questions on that call are what defends it.

How do I check whether my credentials were in a breach without handing them over?

Look the address up at Have I Been Pwned, which needs the address and nothing else. For a password, use its Pwned Passwords search: only the first five characters of a SHA-1 hash leave your machine. What to avoid is typing credentials into a site you have no reason to trust, like the mail that offers to check whether your card was stolen once you supply the number and the CVV.

If an address does turn up, change the password at the named service, change it anywhere you reused it, and turn on a second factor while you’re in the settings.

Related episodes

• #11 AWS Security Maturity Roadmap covers how to rank what you fix first when you can’t fix everything, the work version of the crown jewels question.
• #13 All You Need to Know About Setting Up HashiCorp Vault goes through the setup behind encryption as a service and short-lived credentials.
• #15 Remote Work Security is where we worked through hardware keys, SSH certificates and the alternatives to a flaky VPN.
• #21 Surviving AWS Outage applies the same exit-plan exercise to a cloud provider instead of a password manager.

Resources

• CyberNews, largest compilation of emails and passwords leaked for free, February 2021. The original investigation into COMB: what the archive holds, how little is known about which databases went into it, and why it is a compilation rather than a new breach.
• NYDFS Twitter Investigation Report, October 2020. Settles what actually happened in the July 2020 Twitter takeover: phone calls, no malware, $118,000 in Bitcoin.
• Coveware, Ransomware Payments Fall as Fewer Companies Pay Data Exfiltration Extortion Demands, February 2021. Q4 2020 payment figures, the leak-threat denominator behind them, and which attack vectors led the quarter’s cases.
• NIST SP 800-63B, Digital Identity Guidelines. What a verifier owes you on password handling: checks against known compromised values, long passwords accepted, and no forced periodic rotation.
• Yubico, Can I Duplicate or Back Up a YubiKey?. Why a secret does not come back off the key, why Yubico’s answer is a second registered device, and which credential types you can copy if you saved the secret when you programmed it.
• Troy Hunt, Pwned Passwords V2, February 2018. How the password search answers without receiving the password.
• VeraCrypt. The encrypted container tool behind the pre-encrypted cloud backup approach.
• aws-vault. Keeps AWS credentials out of plaintext files on a laptop.

Since we recorded

Hosted alias services are easy to name now: Apple’s Hide My Email for iCloud+ subscribers, shipped with iOS 15 in September 2021, and SimpleLogin, acquired by Proton in April 2022. In May 2022 Apple, Google and Microsoft committed to expanding their FIDO support: sign-in credentials synced across a user’s devices, and a phone that authenticates a nearby device. The spare-key advice still applies to device-bound credentials, the kind that live on a security key, which FIDO keeps separate from synced passkeys. Secrets in chat we came back to in #81 Keeping Secrets Safe.