Adobe — 153M user credentials

What happened

In early October 2013, security researcher Brian Krebs and Hold Security jointly reported finding a large file on a server used by a known cybercriminal group. The file contained what appeared to be Adobe customer records. Adobe confirmed on 3 October that it had suffered a significant intrusion. The company’s initial disclosure cited approximately 2.9 million records with encrypted payment-card data and login credentials; within weeks, Krebs and independent researchers analysing the leaked file established that the full scope was approximately 153 million user records.

The breach encompassed user IDs, email addresses, encrypted passwords, password hints, and — in a separate portion of the intrusion — source code for several of Adobe’s flagship products: Adobe Acrobat, Adobe Reader, Adobe ColdFusion, and ColdFusion Builder. The payment-card data, while encrypted, was taken from a separate system. Adobe disabled the compromised accounts and invalidated affected passwords, forcing a reset for the affected users.

Adobe at the time operated a subscription model through Adobe Creative Cloud alongside legacy perpetual-licence products, and the user-account infrastructure affected was a combined system serving both. The breach affected both paying customers and users with free accounts, making it one of the largest consumer-facing credential breaches recorded at that time.

No formal attribution was made. Adobe’s subsequent investigation and regulatory interactions did not produce a public identification of the responsible group or nation.

How it worked

Adobe’s password storage mechanism was the defining technical failure of this breach, and the one that made the exposure substantially more damaging than the raw account count suggests.

The passwords were stored using Triple DES (3DES) symmetric encryption. This is a reversible transformation — the same key that encrypts a password can decrypt it back to the original plaintext. This is architecturally incorrect for password storage. The appropriate approach is a one-way cryptographic hash function with per-account random salting (bcrypt, scrypt, or PBKDF2 are standard choices), which makes reversing a stored value computationally infeasible even for an attacker who has both the stored hash and the algorithm. Adobe instead chose a scheme that provided confidentiality only as long as the key remained secret. The attackers obtained, or cracked, the encryption key — meaning every stored password was recoverable.

The shared-key design introduced a second and compounding failure. Because the same encryption key was used for every password, any two users with the same plaintext password produced identical ciphertext in the database. The leaked file therefore displayed patterns invisible in a properly salted hash database: all instances of the ciphertext EQ7fIpT7i/Q= corresponded to the same password, whatever it was. Krebs and researchers from Stricture Consulting used the password-hint field — stored in plaintext adjacent to the ciphertext in the same database — to infer what the most common passwords were. The hint “love” next to thousands of identical ciphertexts; the hint “first name” next to others; “123” next to the most common ciphertext of all. Within days, the top passwords had been identified without any cryptographic attack: the structure of the data made it a frequency-analysis problem. Researchers confirmed that “123456” was the most common password among Adobe’s 153 million users, and that the second most common was “123456789”.

The method of the initial intrusion — how the attackers first obtained access to Adobe’s systems — was not fully detailed in Adobe’s public disclosures. The intrusion reached both the user-account database infrastructure and the source-code repositories, suggesting the attackers had broad access to Adobe’s internal network before exfiltrating the credential file.

The source code theft is a separate concern that was treated as secondary in public coverage but carries longer-term implications. Acrobat and Reader are among the most widely deployed document-processing applications in the world, and ColdFusion is used for web application development. An attacker with access to the full source code of these products is positioned to identify vulnerabilities that may not be visible to external security researchers — and to exploit those vulnerabilities in the wild before they are patched. Whether that occurred is not publicly established.

Timeline

• Unknown date, 2013 — Attackers gain access to Adobe’s internal network. Exact entry vector not publicly confirmed.
• Unknown date, 2013 — Source code repositories for Acrobat, Reader, ColdFusion and ColdFusion Builder accessed and exfiltrated. User credential database accessed.
• Early October 2013 — Brian Krebs and Hold Security discover a large Adobe data file on a server used by a cybercriminal group during an unrelated investigation.
• 3 October 2013 — Adobe publicly discloses the breach. Initial figure given as 2.9 million records with payment data and login credentials. Company states encrypted payment data was also taken.
• 29 October 2013 — Krebs and Stricture Consulting publish analysis of the leaked file, establishing the full count at approximately 153 million records. Krebs demonstrates the password-hint analysis methodology.
• October–November 2013 — Adobe forces password resets for affected accounts. Affected users who used the same password on other services begin receiving breach notifications and account-takeover activity.
• November 2013 — Stricture Consulting publishes a ranking of the top 100 most common passwords derived from the leaked file, including “123456”, “123456789”, “password” and “adobe123”. The hint-analysis methodology becomes a widely cited demonstration of the difference between encryption and hashing.
• 2014–2015 — State attorney general offices in multiple US states investigate and negotiate settlements with Adobe over the breach. Adobe migrates its password storage to bcrypt.
• 2016 onward — Adobe credential records appear persistently in credential-stuffing attack datasets used against other services, demonstrating the multi-year downstream risk of large plaintext-recoverable credential breaches.

What defenders should learn

The central lesson of the Adobe breach is among the most teachable in the security canon: encryption and hashing are different tools with different threat models, and using the wrong one for password storage is not a minor implementation detail. Encryption protects data from observers who lack the key. It does not protect data from an attacker who obtains the key — and in any breach scenario in which the database is exfiltrated, the keys are a logical next target. A cryptographic hash function, applied with a per-record random salt, provides a fundamentally different and appropriate protection: there is no key to steal, and reversing the stored value requires brute-force computation that can be calibrated — via the choice of hash function and its cost parameter — to take as long as the defender wants. bcrypt, scrypt, and Argon2 were all available in 2013. The choice not to use them reflects a design decision whose cost was borne entirely by 153 million users.

The salt-absence problem compounds this. Even where organisations use a hashing function rather than encryption, the omission of per-record random salting allows rainbow table and precomputed-hash attacks to crack entire populations of common passwords simultaneously. Salting ensures that two users with the same password produce different stored values, eliminating batch attacks. It is a one-line change in any competent implementation. The cost of not including it is visible in this breach: the shared-ciphertext analysis methodology that Krebs demonstrated would be impossible against properly salted hashes.

Password hints stored in plaintext are an information-leakage control the Adobe breach makes vivid. A hint is, by design, a clue to the password. Storing hints in the same database as password hashes, accessible to any attacker who reads the database, is storing the password question alongside the (already compromised) answer. Hints should not be stored persistently; if a hint system is offered at all, it should be provided only at the moment of account creation and discarded immediately.

The source code exposure is a reminder that credential databases are rarely the only high-value target in a breach. When attackers reach an organisation’s internal network with sufficient breadth of access to exfiltrate a 153-million-record database, the question of what else they accessed deserves systematic investigation rather than an assumption that only the confirmed exfiltrated data matters.