October 6, 2014 Chris Czub

Adobe Breach Retrospective

TL;DR: The Adobe breach didn’t just affect individuals, but also companies due to password reuse. Users referenced logins to their corporate resources in their password hints, and poor password strength abounded. We’ve set up a site where you can check the leaked Adobe data for affected users in your organization. If you haven’t already, it would be a good idea to reset the passwords for any affected users, particularly if they shared a password between Adobe and your corporate resources. Two-factor authentication would also help mitigate the risk of compromised passwords.

In late 2013, a breach of Adobe’s service led to “certain information relating to 2.9 million Adobe customers” being “removed from Adobe’s systems.” In actuality, the dump that most of us saw had 152,989,508 database rows present; 130,325,756 of which included an encrypted password.

One thing that this leak highlighted to me (and others) was the fact that password hints, while they may seem like a usability/convenience feature for users, can actually be a detriment to user security. It's giving users a way to inadvertently shoot themselves in the foot; for example while looking through the password hints, I found a lot of references to logins on other services. It might be tempting to blame those users for any fallout resulting from their poor password practice, but I’d argue that the service provider has an obligation to promote better security practices among its user base, for example removing the password hint and reminding users to pick a strong password unique to the site when creating their account; and to take the proper steps to ensure the confidentiality and integrity of their service.

Total # Of Password Hints Analyzed: 43,800,682

A password hint can only serve to decrease security: a security-conscious user is likely to be using a password manager (if you aren’t, go get one and use it) with randomly generated passwords, thus a password hint provides no utility. If they’re like me, they’ll type something like “this is stupid” in the hint field. If they use password hint features, users are actively decreasing their security by providing potential for guessing their password. Apple claimed those behind the recent high-profile iCloud celebrity photo “hacking” scandal used password hints to get access to accounts.

Instead of password hints, a preconfigured out-of-band authentication mechanism is a better idea. Password reset emails, even with a temporary or one-time use link, could be susceptible to interception if an attacker also compromised the user's email account. Out-of-band channels such as phone calls or SMS messages are better, but still have their own shortcomings -- mobile malware or a rogue operator could intercept and re-use the material being sent.

Two-factor authentication (2FA) is a great recommendation for protecting unauthorized account access in the case of compromised primary credentials (and we have a good provider to recommend, too!). However, it only works if the organization enables 2FA on every login path. We’ve seen this isn’t always the case, such as when Duo Labs found a bypass of PayPal’s 2FA implementation in their mobile APIs, or when we found a bypass in Google’s 2FA, or when Apple rolled out 2FA across their iCloud services but didn’t include it everywhere.

Many password hints in the dump referenced passwords on other sites. This is dangerous for a number of reasons. Aside from server breaches, end-user phishing and malware are also sources of credential compromise. Thanks to the encryption methods Adobe chose, knowing one user’s password hint and being closer to knowing their password actually makes you closer to knowing other users’ passwords. I’ve seen analysis of the top passwords in the dump, which was obtained via password hints, but didn’t attempt a mass decryption of passwords in the dump via cross-referencing against other sources of passwords and password hints.

Additionally, some users referenced things like their directory services, Novell GroupWise, Zimbra, reused company passwords, and other possible vectors for compromise of corporate data. Because of the risk to corporate data and our dedication to helping companies secure themselves, we’ve taken some proactive steps already; for example we had an email campaign informing some affected companies of the users in their organization whose data was compromised. The intent was to provide affected organizations a high-level view of the user accounts they might want to scrutinize more closely for anything anomalous. Now, as a service to companies who might have been affected by this breach, we have replaced the email campaign with a self-service site that will report on any of your organization’s users that were found in the database dump.

Passwords in the Adobe dump were not repeatedly hashed with a key stretching algorithm such as bcrypt or PBKDF2 as is generally accepted modern security practice when storing passwords. Instead, they were encrypted with a reversible encryption algorithm called triple DES, which signals that there were employees at Adobe who could have accessed your plaintext passwords, at the very least. Additionally, since ECB mode was used, which uses no initialization vector or block chaining, finding matches for known plaintext within larger unknown passwords is possible -- making piecing together longer passwords easier if they contain passwords that are already known.

Here’s where we stand a year later: there have been other known hacks resulting in password compromise, along with harder to quantify events that may have resulted in compromise such as the Heartbleed or Shellshock vulnerabilities.

A California judge has allowed some paying users affected by the Adobe breach to proceed with a class action lawsuit against the company for endangering their safety. They claim the company neglected good security practice and put them at risk of identity theft. The judge agrees, stating they can sue whether or not the breach caused any actual harm based on “the well-established principle that harm need not have already occurred or be 'literally certain' in order to constitute injury-in-fact.” The fact that this case exists shows a promising attitude of accountability.

Software is a younger field than other engineering disciplines and doesn’t have as many controls in place, as much scrutiny of security, or as much accountability as something like mechanical or structural engineering. Much like affected customers would hope a manufacturer of a dangerous vehicle would be held accountable, customers whose safety is affected by a company’s substandard security and software engineering practice should have recourse and be able to seek accountability.