Case Study 28.2: Adobe's ECB Mode Disaster and the Let's Encrypt Revolution

Two Stories of Cryptographic Practice

This case study examines two contrasting stories about cryptography in practice. The first is a cautionary tale: how Adobe's use of Electronic Codebook (ECB) mode to encrypt 153 million user passwords turned what might have been a manageable breach into one of the most instructive security failures in history. The second is an inspirational one: how Let's Encrypt democratized TLS certificates, transforming HTTPS from a luxury into a universal standard and fundamentally changing the web's security posture.

Together, these stories illustrate a central theme of this chapter: the gap between cryptographic theory and practical implementation is where security breaches live, and closing that gap requires both better engineering and better infrastructure.

Part 1: The Adobe Breach — When ECB Mode Exposes Everything

The Breach

In October 2013, Adobe Systems confirmed that attackers had breached their network and stolen source code for several products (including ColdFusion and Acrobat) along with customer data. The initial disclosure mentioned 2.9 million affected accounts. Within weeks, the scope expanded to 38 million. Then, on November 7, 2013, the security researcher Brian Krebs reported that a file containing 153 million user records had been posted on underground forums.

The stolen database contained, for each account: - User ID - Email address - Encrypted password - Password hint (in plaintext)

On the surface, encrypted passwords might seem like a responsible practice -- at least the passwords were not stored in plaintext. But the specific encryption method Adobe chose turned this apparent protection into a goldmine for attackers and a masterclass in cryptographic failure.

The Cryptographic Failure

Adobe encrypted passwords using 3DES (Triple DES) in ECB (Electronic Codebook) mode, with a single key for all passwords.

Let us trace through why each of these choices was catastrophic:

Single Key for All Passwords: Using the same encryption key for every password meant that any identical passwords would produce identical ciphertext. Unlike hashing (which can use per-user salts to ensure uniqueness), symmetric encryption with a shared key and ECB mode provides no such differentiation.

ECB Mode: In ECB mode, each block of plaintext is encrypted independently with the same key. Identical plaintext blocks always produce identical ciphertext blocks. This means: - All users with the password "123456" had exactly the same encrypted value - All users with the password "password" had exactly the same encrypted value - Any user with the same password as any other user was immediately identifiable

3DES Block Size: 3DES uses 64-bit (8-byte) blocks. Passwords shorter than 8 characters produced a single ciphertext block. Passwords between 8 and 16 characters produced two blocks, where the first block was identical for any passwords sharing the same first 8 characters. This leaked tremendous structural information.

The Password Hint Dimension

The password hints were stored in plaintext alongside the encrypted passwords. This created a devastating synergy with the ECB weakness:

1. Group all accounts by encrypted password value (identical encrypted values = identical passwords)
2. Read the password hints from all accounts in each group
3. Deduce the password from the combined hints

For example, one encrypted password value appeared 1.9 million times (it was "123456"). The password hints for these accounts included: "numbers," "one two three," "easy," "counting," "123456" (some users put the actual password as their hint), and "a]1b]2c]3." No cryptanalysis was necessary -- the hints told you the password.

The security researcher Jeremi Gosney demonstrated that the top 100 most common encrypted password values -- representing tens of millions of accounts -- could be determined almost entirely from password hints alone, without any computational attack on the encryption.

The XKCD Effect

The breach became a cultural moment when Randall Munroe published XKCD comic #1286, which presented a crossword puzzle where the clues were groups of password hints from the Adobe breach and the answers were the corresponding passwords. Clues like "tis the season to be" (answer: "jolly"), "what I eat for dinner" (answer: "pizza"), and "girl's name" combined with "my cat" and "my dog" (answer: common pet names that doubled as passwords) demonstrated how thoroughly ECB mode had compromised user security.

What Adobe Should Have Done

The correct approach for password storage was well-established by 2013:

1. Hash, do not encrypt. Passwords should be hashed, not encrypted. There is no legitimate reason to decrypt a user's password -- you only need to verify it by comparing hashes.

2. Use a password-specific hash function. bcrypt (available since 1999), scrypt (available since 2009), or later Argon2. These functions are deliberately slow and memory-intensive, making brute-force attacks expensive.

3. Use a unique salt per password. Even if the hash function is fast (like SHA-256, which should not be used for passwords), a per-user random salt ensures that identical passwords produce different hashes.

4. Never store password hints. If hints are needed, they should be treated with the same security as the password itself.

With bcrypt and per-user salts, the 153 million password database would have been a collection of unique, computationally expensive-to-crack hashes. Even the weakest passwords would have required individual brute-force attacks rather than the trivial group deduction that ECB mode enabled.

The Aftermath

The breach had significant consequences:

• $1.18 million settlement with 15 state attorneys general
• Undisclosed settlement with users in a class-action lawsuit
• Mandatory password resets for all 153 million accounts
• Password hash migration to bcrypt (implemented after the breach)
• Regulatory scrutiny and reputational damage

Adobe's breach was cited by NIST in its updated Digital Identity Guidelines (SP 800-63B) as an example of why proper password storage is essential. The breach also contributed to the industry-wide movement away from password-based authentication toward multi-factor authentication and passwordless solutions.

Technical Analysis: ECB Mode Visualization

To understand the ECB problem viscerally, consider a simplified example:

Passwords and their 3DES-ECB encrypted values (simplified):

Password: "password"  ->  Encrypted: [BLOCK_A]
Password: "password"  ->  Encrypted: [BLOCK_A]  (identical!)
Password: "passw0rd"  ->  Encrypted: [BLOCK_B]  (different)
Password: "password1" ->  Encrypted: [BLOCK_A][BLOCK_C]  (first block identical to "password"!)
Password: "12345678"  ->  Encrypted: [BLOCK_D]
Password: "12345678"  ->  Encrypted: [BLOCK_D]  (identical!)

Grouping by encrypted value immediately reveals password reuse patterns: - 1,911,938 accounts shared [BLOCK_D] (password: "123456") - 446,162 accounts shared [BLOCK_A] (password: "password") - 345,834 accounts shared another value (password: "123456789")

This grouping, combined with plaintext hints, made password recovery trivial for tens of millions of accounts.

Part 2: Let's Encrypt — Democratizing HTTPS

The Problem

Before 2015, obtaining an SSL/TLS certificate was expensive, complicated, and manual. Domain-validated (DV) certificates cost $10-100 per year. Extended validation (EV) certificates cost $100-1,000. The process involved:

1. Generate a private key and Certificate Signing Request (CSR)
2. Submit the CSR to a Certificate Authority
3. Complete domain validation (email, DNS, or HTTP challenge)
4. Receive the certificate (often hours or days later)
5. Install the certificate on the web server
6. Configure the web server for TLS
7. Renew every 1-3 years (and remember to do so)

The result was predictable: as of 2014, less than 30% of web traffic was encrypted. Most small websites, personal blogs, open-source projects, and small businesses operated without TLS. Users were habituated to the "Not Secure" label (or, more commonly, the absence of any security indicator).

This had real security consequences: - Session hijacking: Tools like Firesheep (2010) demonstrated that anyone on a public Wi-Fi network could hijack sessions from unencrypted websites - Content injection: ISPs and network operators could (and did) inject ads, tracking scripts, and even malware into unencrypted HTTP traffic - Mass surveillance: Government surveillance programs could trivially monitor unencrypted web traffic at scale - MITM attacks: Without TLS, any network intermediary could modify content in transit

The Solution

The Internet Security Research Group (ISRG), in partnership with the Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, and the University of Michigan, launched Let's Encrypt in April 2016. Its mission was simple: make TLS certificates free, automated, and universal.

Key Design Principles:

1. Free: No charge for certificates, ever. Funded by corporate sponsorship and donations.

2. Automated: The ACME (Automatic Certificate Management Environment) protocol enables fully automated certificate issuance and renewal. No human intervention required.

3. Open: The ACME protocol is an open standard (RFC 8555). The CA software (Boulder) is open source. CT logs are publicly accessible.

4. Short-lived: Certificates are valid for only 90 days (vs. the 1-3 year validity of traditional certificates). This reduces the window of exposure from compromised keys and incentivizes automation.

The ACME Protocol

The ACME protocol automates the entire certificate lifecycle:

1. Account creation: The client generates a key pair and registers with Let's Encrypt
2. Order: The client requests a certificate for one or more domain names
3. Authorization: Let's Encrypt issues challenges to prove domain control: - HTTP-01: Place a specific file at http://domain/.well-known/acme-challenge/token - DNS-01: Create a specific DNS TXT record for _acme-challenge.domain - TLS-ALPN-01: Respond with a specific self-signed certificate on TLS connection
4. Validation: Let's Encrypt verifies the challenge from multiple network perspectives
5. Issuance: Let's Encrypt issues the certificate (valid for 90 days)
6. Renewal: The client automatically renews before expiration (typically at 60 days)

The reference ACME client, Certbot, handles this entire process with a single command:

certbot --nginx -d example.com -d www.example.com

This command generates a key, obtains a certificate, configures Nginx for TLS, and sets up automatic renewal via cron/systemd timer.

The Impact

Let's Encrypt's impact on internet security has been transformative:

By the numbers (as of 2025): - Over 400 million active certificates - Over 350 million unique domains served - HTTPS adoption on the web has grown from approximately 30% (2014) to over 95% (2025) - Let's Encrypt is the world's largest certificate authority by volume

Cultural shift: - Browsers now show "Not Secure" warnings for HTTP pages (Chrome since July 2018) - Search engines prioritize HTTPS sites in rankings (Google since 2014) - Modern web APIs (geolocation, camera, microphone, service workers) require HTTPS - HTTP is now the exception rather than the default

Security improvements: - Mass surveillance of web traffic is significantly harder - Content injection by ISPs and intermediaries is prevented - Session hijacking on public Wi-Fi requires active MITM rather than passive sniffing - Certificate Transparency provides unprecedented visibility into certificate issuance

Security Implications and Criticisms

Let's Encrypt is not without criticism and security implications:

Domain Validation Only: Let's Encrypt only performs domain validation (DV), not organization validation (OV) or extended validation (EV). This means it verifies that the certificate requester controls the domain, but not their identity. Phishing sites can (and do) obtain Let's Encrypt certificates, showing a padlock icon to victims.

Automated Issuance and Abuse: The same automation that makes Let's Encrypt accessible also makes it accessible to attackers. Malware C2 servers, phishing sites, and other malicious infrastructure routinely use Let's Encrypt certificates.

Short Certificate Lifetime: The 90-day validity period is a security benefit (limiting exposure from key compromise) but creates a dependency on automation. If the renewal process breaks, websites go down.

Certificate Transparency: All Let's Encrypt certificates are logged in CT logs, providing security monitoring value but also enabling reconnaissance (as we discussed in Section 28.4).

Implications for Penetration Testing

Let's Encrypt has changed the penetration testing landscape in several ways:

1. Ubiquitous TLS: Websites that were previously HTTP-only now use HTTPS by default, requiring TLS assessment as a standard part of every engagement.

2. C2 Infrastructure: Red teams use Let's Encrypt for legitimate TLS on their C2 infrastructure, making their traffic look like normal HTTPS to network monitors.

3. Certificate Monitoring: CT log monitoring for unexpected certificate issuance is now a viable detection strategy. If a Let's Encrypt certificate appears for a subdomain that already has a commercial certificate, it may indicate a subdomain takeover or unauthorized server.

4. Phishing Campaigns: In authorized social engineering engagements, Let's Encrypt makes it trivial to set up HTTPS-enabled phishing pages, testing whether users rely on the padlock icon for trust decisions.

Connecting the Stories

Adobe's ECB mode disaster and Let's Encrypt's revolution are connected by a common theme: the practical implementation of cryptography matters more than the theoretical strength of the algorithms.

Adobe had encryption but used it wrong. 3DES is a reasonable (if dated) algorithm. But ECB mode with a single key turned encryption into a liability rather than a protection. The lesson: choosing the right algorithm is necessary but not sufficient. Mode of operation, key management, and overall system design are equally important.

Let's Encrypt made encryption accessible. The TLS protocol stack was cryptographically sound by 2015 -- TLS 1.2 with AEAD ciphers was provably secure. But the certificate ecosystem (expensive, manual, error-prone) prevented widespread adoption. The lesson: cryptographic security requires not just good algorithms but also good infrastructure, usability, and economic incentives.

For MedSecure

These lessons apply directly to our MedSecure engagement:

• Password storage: Are MedSecure's patient passwords hashed with bcrypt/Argon2, or are they encrypted (or worse, stored in plaintext)?
• TLS configuration: Is the patient portal using a Let's Encrypt certificate with auto-renewal, or a manually managed certificate that might be expired, misconfigured, or using weak settings?
• Legacy systems: Are any medical devices using obsolete encryption (DES, RC4, ECB mode) that creates hidden vulnerabilities?
• Certificate management: Does MedSecure have visibility into all certificates issued for their domains through CT log monitoring?

Discussion Questions

1. Adobe encrypted passwords rather than hashing them. Under what circumstances (if any) would encrypting passwords be appropriate? Why is hashing generally preferred?

2. The password hints stored alongside Adobe's encrypted passwords were arguably more damaging than the encrypted passwords themselves. Should applications ever offer password hints? What alternatives exist?

3. Let's Encrypt's DV certificates do not verify organizational identity. A phishing site for med-secure-login.com can obtain a valid certificate and show a padlock icon. How should users (and browsers) handle this trust problem?

4. Let's Encrypt certificates are valid for 90 days, requiring reliable automation. For MedSecure's patient portal, what risks does short certificate lifetime create, and what mitigations would you recommend?

5. If Adobe had used AES-256-GCM instead of 3DES-ECB, would the breach outcome have been significantly different? Why or why not? (Hint: consider the fundamental question of encryption vs. hashing for passwords.)

Timeline

References

• Krebs, B. (2013). "Adobe Breach Impacted At Least 38 Million Users." KrebsOnSecurity.
• Gosney, J. (2013). "Adobe Password Crossword." Stricture Consulting Group.
• Munroe, R. (2013). "XKCD #1286: Encryptic." xkcd.com.
• NIST. (2017). "Digital Identity Guidelines: Authentication and Lifecycle Management." SP 800-63B.
• Aas, J. et al. (2019). "Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web." ACM CCS 2019.
• Barnes, R. et al. (2019). "Automatic Certificate Management Environment (ACME)." RFC 8555.
• Electronic Frontier Foundation. (2016). "Certbot: Automatically Enable HTTPS." certbot.eff.org.
• Let's Encrypt. "Statistics." letsencrypt.org/stats.
• Google Transparency Report. "HTTPS Encryption on the Web." transparencyreport.google.com.