3 September 2026
Nobody breached Dropbox
Around 5,000 accounts were compromised anyway, and files were viewed or downloaded from roughly 1,500 of them. The interesting part isn't a failure of Dropbox's security. It's what a design decision costs when something upstream goes wrong.
In August, attackers got into about 5,000 Dropbox accounts. They did it without breaking any encryption, without exploiting Dropbox's servers, and without knowing a single victim's password.
They just asked to be let in, and the front door agreed.
What actually happened
Dropbox lets you sign in through other identity providers. One of them was Lenovo. Lenovo's account registration had a flaw in how it verified email addresses: an attacker could register a Lenovo ID using someone else's email address without ever proving they controlled it.
From there the path was short. Create a Lenovo ID against a target's email address, use it to sign in to Dropbox, and arrive inside the account. Reporting on the incident notes that the affected accounts did not have two-factor authentication enforced on that path, so there was no second obstacle. As one security adviser quoted in the coverage put it, the attackers had "full access without needing a password".
Unauthorised activity ran through the first three weeks of August 2026. Files were viewed or downloaded from around 1,500 accounts. Dropbox expired every session authenticated through a Lenovo ID, severed the integration, now requires a Dropbox password when signing in that way, emailed the people affected, and reported the incident to data protection regulators.
To be fair to Dropbox: their systems were not breached. The verification flaw was in someone else's product, the response was fast, and reporting it to regulators was the right call. Any company that federates login to a third party is exposed to that third party's mistakes, and most large services federate login to somebody. This could have been a lot of people's incident.
The part worth thinking about
Almost every conversation about cloud storage security is about whether the provider can be breached. Do they encrypt at rest? Where are the servers? What certifications do they hold?
All reasonable questions, and all slightly beside the point here, because nobody had to breach anything. The attackers became the user. And when a service can read your files on your behalf, anyone who convincingly becomes you can read them too.
That reframes the risk. The question isn't only "how good is my provider's security?" It's "how many ways are there to become me, and what happens at the end of each one?" The list is longer than most people assume: a password reset, a SIM swap, a support agent socially engineered, a stolen session cookie, an OAuth token with too much scope, a federated identity provider with a verification bug. Every one of those ends at the same place, and if your files are readable by the service, they are readable at the end of every path.
Encryption at rest — the kind almost every provider advertises — does nothing about this. The provider holds those keys and applies them automatically for whoever is logged in. It protects against a stolen hard drive. It does not protect against someone wearing your face.
What we build instead
enblob is a sync client, not a storage service. That sounds like a small distinction and it changes the whole shape of this problem.
Your files go to storage you own — an S3-compatible bucket you configure and pay for. We never receive them. And if you use one of the strong encryption modes, the key is generated on your machine and never leaves it, so what lands in your bucket is ciphertext.
So consider the same attack against us. Suppose someone defeats our sign-in completely and lands inside an enblob account. What have they got?
An email address. An installation identifier. An app version, an operating system, a processor architecture. A one-way hash that identifies a bucket without naming it. That's the lot — there are no files in an enblob account, because an enblob account is a licensing record. There's nothing there to download.
To reach your actual files, an attacker needs the S3 credentials sitting on your device. And to read them after that, they need an encryption key that was never sent to us and is not in the bucket.
What survives what
Being concrete about this is more useful than adjectives:
| If this happens | Then |
|---|---|
| Someone takes over your enblob account | They get the metadata listed above. No files, no keys, not even your bucket's name. |
| Your storage provider is breached, or your bucket is copied wholesale | In password or key-file mode they hold ciphertext. The key was never in the bucket and never on our servers. |
| enblob is compromised, or served a legal demand | We can produce what we hold, which is the metadata. We cannot produce file contents or keys, because we never had them. |
| Your S3 credentials leak | Your files stay unreadable, but the holder can delete or overwrite objects. Rotate the key; keep versioning on. |
| Your laptop is compromised | Encryption doesn't save you. The key lives there by necessity. No architecture fixes this one. |
Where this argument stops
A post like this is easy to overclaim, so here is the boundary.
We would not have prevented the Dropbox incident. Nothing about our design stops a third party from mis-verifying an email address. What changes is the consequence. In an architecture where the account holds the files, a successful impersonation is a data breach. In one where the account holds a licence record, it is an annoyance.
One of our modes would not have helped either. enblob offers an obfuscation mode that scrambles files with a key embedded in the application binary. It defeats automated scanning, and it will not stop anyone who knows what enblob is and is willing to pull the key out of a public binary. It is there for convenience on non-sensitive data. For anything you would actually mind losing, use password or key-file mode. We say the same thing in the setup wizard, at the moment you choose.
And we are not in a position to be smug. enblob is in early access. We have written our share of bugs and will write more. What we can say is narrower and more durable than "trust us": there is no pile of readable customer files at enblob for anyone to steal, and no key we could be compelled to hand over. That property comes from the architecture rather than from our good intentions, which is the only kind of security promise worth much.
What to do this week, whatever you use
Most of this is worth doing on Dropbox, Google Drive, or anything else. None of it requires switching to us.
- Audit which identity providers can sign in as you. Check the connected-accounts or SSO section of every service holding anything you care about, and disconnect the ones you no longer use. Each one is a separate way to become you.
- Enforce two-factor authentication on every path, not just the main one. This incident turned on accounts where the federated route skipped it. An account is only as protected as its weakest way in.
- Ask what your provider can read. "Encrypted at rest" usually means the provider holds the keys. That is a different promise from "we cannot read your files", and only the second one survives an account takeover.
- Turn on object versioning if you run your own storage. It is the cheapest protection against deletion and ransomware there is, and it sits entirely outside whichever sync tool you use.
- Keep real backups. Sync is not backup. Anything that faithfully replicates your changes will faithfully replicate a deletion.
The short version
Five thousand accounts were opened without a single password being cracked, because identity is a much broader attack surface than infrastructure, and because at the end of every path into those accounts sat readable files.
You cannot make impersonation impossible. You can decide what it's worth when it works.