On December 22, 2022 — three days before Christmas, a fine season for burying bad news — LastPass updated the world on a security incident it had first disclosed in August. The August version had been soothing. Someone had slipped into the company's development environment and made off with source code and some technical information. No customer data was touched, the company said. No vaults.
The December version read differently. The intruders, it turned out, had used what they learned in August to come back — and this time they copied backups of customer vault data. Not a mailing list. Not a billing database. The vaults: the one product whose entire reason for existing was to never end up in someone else's hands.
WATCH · 29 SECONDS
Almost everyone has a secret. Almost no one has a safe place for it.
See how Everkeep keeps your most private data offline — numbered, sealed, and watched.
Start protecting — $199/yrThe first breach was reconnaissance
In August 2022, an attacker got hold of a developer's credentials and spent days inside LastPass's development environment, taking portions of the company's source code and proprietary technical information. LastPass brought in outside investigators, contained the intrusion, and told customers their data and vaults had not been accessed. As far as anyone could tell, that was true — and beside the point.
Armed with the technical information from that first incident, the attacker targeted another employee, obtained credentials, and reached a third-party cloud storage service where LastPass kept backups. From there, copies of customer account information and vault backups were taken. The August breach was never the real event. It was the reconnaissance. December was the job itself.
This is a pattern we've seen often enough to have a name for it in hindsight: the first incident is rarely the disaster. It's the map being drawn for the second one.
They encrypted the contents. They left the map in plain sight.
To be fair to the cryptography: the sensitive fields inside a LastPass vault — usernames, passwords, secure notes, form-filled data — were encrypted with 256-bit AES, using keys derived from each user's master password. LastPass couldn't read them. That part of the design was sound, and as far as public reporting goes, the encryption itself has not been broken.
But the vault backups also carried data that was never encrypted at all. The website URLs attached to each saved login sat in plain text, alongside customer names, email addresses, billing addresses, phone numbers, and the IP addresses users connected from.
Consider what that means. The attackers received two things: the locked boxes, and — separately, in the clear — a complete index of what was locked and where it belonged. A person's vault URLs are a map of their life. Their bank. Their email provider. Their brokerage and their crypto exchange. Their employer's systems, their clinic's patient portal, the accounts they'd rather not discuss. You don't need to open a single vault for that map to be valuable. It tells a phisher exactly which institutions a target uses and what a convincing fake email should pretend to be. LastPass itself warned customers to expect exactly those phishing attempts.
They encrypted the diary. They published the table of contents.
One password, and all the time in the world
For the encrypted contents, everything rests on the master password — by design. What December changed is where the guessing happens. A stolen backup is an offline problem now. The copy sits on the attacker's own hardware. There is no login page counting failed attempts, no lockout after ten tries, no alert landing in anyone's inbox. Every guess is free, silent, and unhurried — forever.
A long, unique master password on an up-to-date account makes a vault a genuinely hard target; the math holds. A short, familiar, or reused one is a different story — it becomes a question of computing power and patience. And account settings varied widely: older accounts often carried far weaker key-derivation settings than the company's own later recommendations, which means two customers with the same password could have very different levels of protection and no way of knowing it.
So the safety of the whole archive came down to things no customer could inspect: the strength of one memorized phrase, and the operational discipline of a company whose development environment had already been entered once that year. That is a great deal of weight resting on a single point. Single points are where systems fail.
What is actually yours to govern
Seneca's letters return, again and again, to a plain division: some things are up to us, and some things are not, and a settled mind comes from knowing which is which. You cannot govern a vendor's development environment. You cannot vet their employees, audit their storage providers, or reschedule their December disclosures. If your most sensitive material lives inside someone else's product, then part of its safety is a function of other people's competence — people you will never meet, working on systems you will never see.
What you can govern is the decision underneath: what lives where. A password manager is a reasonable tool for the logins of daily life, and most of daily life can tolerate the risk. But the archive beneath the logins — the journals, the photographs, the records you would hand to no one — does not have to be a feature of someone's platform, replicated across their backup storage, waiting for their bad December.
A drive you encrypted yourself has no copy in a vendor's cloud and no index in plain sight. It has a location, a seal, and a key that exists only in your head. We've learned that this is what people actually mean by secure: not a stronger promise from a larger company, but fewer strangers standing between them and the things they cannot replace.
Everkeep provides offline custody for encrypted drives you own and encrypt yourself. We number, seal, photograph, and store them — two copies, two locations — and we never see inside. $199/year per device slot.