Adobe Breach 2013: 153 Million Passwords and a Crypto Blunder

On October 3, 2013, Adobe published a short statement: attackers had broken into its network, copied nearly 3 million customer card records and taken source code for products such as ColdFusion. The number looked manageable. Weeks later, a file with more than 150 million username/password pairs surfaced on a forum, and the case became a textbook example of how not to protect passwords. Thirteen years on, the same mistake is still being made.

What Adobe said and what really leaked

The first report came from KrebsOnSecurity. Journalist Brian Krebs and researcher Alex Holden of Hold Security had found roughly 40 GB of source code on a server controlled by the intruders about a week before the announcement. Adobe confirmed the incident and spoke of (encrypted) card records and of credentials for an as-yet-undetermined number of accounts.

The number grew. On October 29, Adobe itself admitted the attack reached about 38 million active users, and that part of the Photoshop source code was also accessed, on top of Acrobat, Reader and ColdFusion. Shortly after, a file with more than 150 million username and password pairs was posted on AnonNews.org. Have I Been Pwned indexed 152.4 million accounts, each with an email, username, encrypted password and a plaintext password hint.

The gap between 38 million active users and 150 million in the dump comes from old, inactive accounts that Adobe kept in its database. People who didn't even remember signing up were in there.

Why the password encryption was the real disaster

Leaking a password database is bad, but the impact depends on how the passwords were stored. The correct approach is to store a salted hash such as bcrypt, scrypt or Argon2: a one-way function, deliberately slow, where each password gets its own random value. Adobe did something else.

How did Adobe store passwords?

With reversible symmetric encryption: 3DES in ECB mode, using a single key for every user. It wasn't a hash. Anyone who got the key could undo everything, and even without it the design gave away a lot.

ECB mode encrypts each 8-byte block independently, with no salt and no randomness. The direct consequence: identical passwords produce identical ciphertexts. All you had to do was sort the dump by frequency. The value that appeared most often was, almost always, the most popular password. The analysis published by Sophos showed exactly that, and 123456 topped the ranking.

What did plaintext password hints cause?

They worked as an answer key. With thousands of accounts sharing the same ciphertext, reading the hints from those accounts was enough to deduce the password for all of them. Hints like "the first six numbers" or "keyboard, top row" solved the puzzle without breaking anything. Some users even used the hint to mention the company or system they worked at, which became fuel for social engineering.

The case turned into a technical joke. xkcd's Encryptic comic, published in November 2013, poked fun at deducing passwords from hints and repeated blocks.

The domino effect: password reuse

The bigger damage didn't stay at Adobe. People who used the same password for email, banking or social networks became targets of automated login attempts on other sites, a technique now called credential stuffing. An old leak stays useful to an attacker until the victim changes the password everywhere.

Adobe forced password resets on the affected accounts and notified users, but notifications to customers outside the US took weeks, according to coverage at the time. At a similar scale, the 2013 Yahoo breach showed the other side: the company took years to size up the damage.

What you can do today

• Check your email on Have I Been Pwned. If it shows up in the Adobe breach, treat any old password as burned.
• One password per service. A password manager like Bitwarden generates and stores everything, so you don't have to memorize anything.
• Never write a hint that reveals the password. If a service asks for one, write something that only makes sense to you, or nothing.
• Turn on 2FA wherever you can. If possible, move to passkeys, which don't rely on a reusable password.
• If you're a developer: use bcrypt, scrypt or Argon2 with a per-user salt. Never encrypt passwords with a reversible key, and never use ECB for anything that matters.

The bigger lesson

Encryption and hashing solve different problems, and confusing the two was Adobe's central mistake. Encrypting means there is a way back, and whoever steals the key along with the database gets everything. A slow, salted hash means the attacker has to guess password by password, and each guess costs time. The 2013 incident became required reading in security courses for exactly that reason: it was the most instructive mistake possible, with 153 million examples.

If you want to keep following this thread, read about the 2017 Equifax breach, which shows another kind of basic failure with enormous consequences.