MyRecon OSINT

← Case Files · The Breach Files

2012 · Cloud storage

Dropbox, 2012: an employee reused a password, and 68 million accounts followed

Case file · 3 min read · Published 14 September 2026

People affected
68.6 million accounts
When it happened
Mid-2012
Made public
Confirmed at the time as an email exposure; full scale revealed August 2016
How they got in
An employee's password, stolen in the LinkedIn breach, reused on a corporate account
Attributed to
Yevgeniy Nikulin, convicted in the United States in 2020

What was exposed: Email addresses · Password hashes — about half bcrypt, about half salted SHA-1

Dropbox's 2012 breach is the shortest causal chain in this archive. An employee used their LinkedIn password on a Dropbox corporate account. LinkedIn was breached. Somebody tried the password. Sixty-eight million user credentials went out of the door — and nobody outside the company knew the real size of it for another four years.

What happened

In mid-2012, Dropbox disclosed that a stolen employee credential had been used to access a document containing user email addresses, which explained a wave of spam that users had been reporting. At the time, that was the story: a limited exposure, addresses only.

In August 2016 a file containing 68.6 million Dropbox account records — email addresses and password hashes — surfaced publicly, in the same wave of aged datasets that brought LinkedIn and MySpace to market. Dropbox confirmed it was from the same 2012 incident and forced a password reset for every account that had not changed its password since.

The intrusions were later tied to Yevgeniy Nikulin, who was convicted in the United States in 2020 for the LinkedIn, Dropbox and Formspring breaches.

The bit Dropbox got right

It is worth being fair here, because this archive is mostly a record of poor decisions and this was not one.

The hashing was good for 2012. Roughly half the passwords were hashed with bcrypt — a slow, salted, purpose-built password algorithm — and the remainder with SHA-1 plus a salt. Compare that with LinkedIn's unsalted SHA-1 the same year, or Adobe's reversible encryption the year after. The practical consequence is that the Dropbox file has never produced the mass password recovery that those breaches did. The credentials leaked; most of the passwords did not.

This is the strongest available argument for spending engineering time on password storage. It is invisible work that pays out only once, on the worst day, and on that day it is the difference between a notification and a catastrophe.

The bit that should have been prevented

The entry point was an employee using one password in two places, one of which was a company they did not control.

In 2012 this was a widely tolerated habit. Today the controls are standard and none of them are expensive:

  1. Single sign-on, so employees have far fewer passwords to reuse in the first place.
  2. Phishing-resistant multi-factor authentication on every corporate account, so a correct password alone is not sufficient.
  3. A managed password manager, provided and mandated, so unique passwords are the path of least resistance.
  4. Credential monitoring against breach corpora for corporate domains, to detect exactly this pattern before an attacker does.

Every one of those exists because of cases like this one. The reason they get funded is that the alternative is being the second victim of a breach at a company you have never done business with.

What it changed

Password reuse became a board-level risk, not a hygiene lecture. The Dropbox chain is the standard slide in security awareness training for a reason: it is short, true, and shows the transmission mechanism clearly.

Breach scope acquired a permanent asterisk. Dropbox described what it knew in 2012 and was not being evasive; it simply did not know the rest until the file appeared. Anyone reading a fresh breach notice should assume the same is true of it.

Forced resets on stale passwords became normal. Dropbox's 2016 response — reset every password unchanged since the incident — is now the expected remediation when an old credential file resurfaces.

If you had a Dropbox account before 2013

  1. The password was probably not cracked, but assume it was anyway. Good hashing reduces risk; it does not eliminate it, particularly for weak passwords.
  2. Check for reuse of that password elsewhere, especially on accounts you have held for a long time.
  3. Turn on two-factor authentication on cloud storage specifically. Storage accounts hold the documents that let someone impersonate you everywhere else — the options compared.
  4. Review what is still in there. Old cloud storage accumulates scans of passports, tax returns and contracts that nobody would upload today — an audit worth an afternoon.

Checked against every breach on record, against public breach data only. Your address is not sent to us as a form and is not stored — it is handed straight to the lookup tool in your own browser. See the privacy policy.

Questions people ask

How were Dropbox and LinkedIn connected?

A Dropbox employee used the same password on LinkedIn and on a Dropbox corporate account. The LinkedIn breach put that password into circulation, someone tried it against Dropbox, and it worked. Dropbox itself was not vulnerable to anything except its employee's password habits.

Were the Dropbox passwords cracked?

Largely not. About half the hashes used bcrypt, which is designed for password storage and resists large-scale cracking; the rest used SHA-1 with a salt, which is weaker but far better than the unsalted hashes of the era. This is a case where good storage choices materially limited the damage.

Why did it take four years to learn the real scale?

In 2012 Dropbox disclosed that a stolen employee credential had exposed a document containing user email addresses, and users saw a wave of spam. The full credential file did not surface publicly until August 2016, when it appeared in the same wave of old datasets as LinkedIn and MySpace. Dropbox then forced a password reset for accounts that had not changed since 2012.

What is the actual lesson?

That employee password reuse is a corporate risk, not a personal one. Enforcing a password manager, phishing-resistant multi-factor authentication and single sign-on for staff is the control — and it is cheaper than being the second victim of somebody else's breach.

Sources

Read next

Case files are written from the public record: regulatory findings, court filings, company disclosures and contemporaneous reporting, cited above. Figures are the ones the organisation or its regulator finally settled on, which is often not the number first reported — where that differs, the page says so. Disputed accounts are marked as disputed rather than resolved in either direction.

← All case files Breach archive →