The Secure Times

An online forum of the ABA Section of Antitrust Law's Privacy and Information Security Committee


1 Comment

The Adobe Data Breach and Recurring Questions of Software Liability

In recent weeks, news and analysis of the data breach announced by Adobe in early October has revealed the problem to be possibly much worse than early reports had estimated. When Adobe first detected the breach, its investigations revealed that “certain information relating to 2.9 million Adobe customers, including customer names, encrypted credit or debit card numbers, expiration dates, and other information relating to customer orders” had been stolen through a series of sophisticated attacks on Adobe’s networks. Adobe immediately began an internal review and notified customers of steps they could take to protect their data. Security researchers have since discovered, however, that more than 150 million user accounts may have been compromised in this breach. While I make no assertions regarding any potential claims related to this breach, I believe the facts of this incident can help convey the difficulties inherent in the ongoing debate over liability in cybersecurity incidents.

The question of whether software companies should be held liable for damages due to incidents involving security vulnerabilities or software bugs has been kicked around by scholars and commentators since the 1980s—centuries ago in Internet time—with no real resolution to show for it. Over the past month, Jane Chong has written a series of articles for the New Republic which revives the debate, and argues that software vendors who do not take adequate precautions to limit defects in their code should bear a greater share of the liability burden when these defects result in actual damages. This argument may seem reasonable on its face, but a particular aspect of the recent Adobe data breach illustrates some of the complexities found in the details that should be considered a crucial part of this debate. Namely, how do we define “adequate” or “reasonable” when it comes to writing secure software?

As Adobe correctly pointed out in their initial announcement, the password data stolen during the data breach was encrypted. For most non-programmers, this would appear to be a reasonable measure to protect sensitive customer data. The catch here lies in two core tenets of information security: First, cryptography and information security are not the same thing, and second, securing software of any complexity is not easy.

When Adobe encrypted their customer passwords, they used a well-known encryption algorithm called Triple DES (3DES) in what is called ECB mode. The potential problem is not in the encryption algorithm, however, but in its application. Information security researchers have strongly discouraged the use of cryptographic algorithms like 3DES—especially in the mode Adobe implemented—for encrypting stored passwords, since it uses a single encryption key. Once a hacker cracks the key, all of the passwords become readable. In addition, since 3DES in ECB mode will always give the same encrypted text when using the same plain text, this enables hackers to use guessing techniques to uncover certain passwords. These techniques are made easier by users who use easily guessed passwords like “123456” (used by two million Adobe customers). When you consider that many Adobe customers use the same password for multiple different logins, which may include banks, health care organizations, or other accounts where sensitive information may be accessed, one can see the value of this Adobe customer data to hackers.

From an Adobe customer’s perspective, it may seem reasonable that Adobe bear some of the liability for any damages that might result from this incident. After all, the customer might reason, Adobe’s network was breached, so Adobe did not do enough to protect customer data. On the other hand, Adobe could justifiably point out that it had taken reasonable precautions to protect their networks, including encrypting the sensitive data, and it was only due to a particularly sophisticated attack that the data was stolen. Further, Adobe could argue, if a customer used an easily guessed password for multiple logins, there is nothing Adobe can do to prevent this behavior—how could it be expected to be liable for digital carelessness on the part of its customers?

These questions will not be answered in a few paragraphs here, of course, but it is clear that any discussion of software liability is not necessarily analogous to product liability theories in other industries, like airlines or cars. Rather, software engineering has its own unique considerations, and we should be careful not to slip too easily into convenient metaphors when considering questions of software liability. Secure software development can be difficult; we should expect no less for questions of law related to this industry.


Leave a comment

California Continues to Expand Consumer Privacy Protections, Enacting Further Amendments to CalOPPA and the Data Breach Notification Law

On September 27, California Governor Jerry Brown signed into law two bills—both to take effect January 1, 2014—that expand the online privacy protections for California residents.  These two new laws were the second and third enacted during September, as the Governor signed a bill imposing restrictions on the advertising of certain products marketed to minors earlier that week, and demonstrate that the California legislature continues to prioritize consumer privacy by amending its legislation to reflect changes in the way websites collect, and consumers provide, personal information online.

“Do Not Track” Disclosures

The first bill, AB 370, amends the California Online Privacy Protection Act (“CalOPPA”) (Cal. Bus. & Prof. Code § 22575 et seq.), requiring that the privacy policy posted on all commercial websites include a disclosure explaining how the website operator responds to mechanisms, such as “Do Not Track” signals, that provide consumers with the ability to exercise choice regarding personally identifiable information collection over time and across third-party websites.

The new law states that website operators may satisfy this requirement by providing a clear and conspicuous hyperlink in the privacy policy that links to a description, including the effects, of any program or protocol the operator follows that offers consumers that choice, but defines neither the content of the disclosure nor “do not track.”

Data Breach Notification for Disclosure of Online Account Access Information

The second bill, SB 46, amends California’s data breach notification law (Cal. Civ. Code § 1798 et seq.), adding to the definition of “personal information” certain information that would permit access to an online account, and imposing additional disclosure requirements if a breach involves personal information that would permit access to an online account or email account.  Specifically, the legislation adds to the definition of personal information “a user name or email address, in combination with a password or security question and answer that would permit access to an online account.”   A breach of this information, if unencrypted, of any California resident would trigger the state’s data breach notification obligations.

In the case of disclosure of this type of personal information, however, a company will be permitted to notify affected California residents by alternative means.  If the breach involves no other personal information, a company may notify the affected resident in electronic or other form that directs the resident to change his/her password and security question or answer, as applicable, or to take other steps appropriate to protect the affected online account and all other online accounts with the same user name or email address and password or security question and answer.

However, if the breach involves the login credentials of an email account furnished by the company, it cannot provide notification to that email address, but may provide notice by:  (1) one of the methods currently permitted under the law for notification of a breach of unencrypted personal information; or (2) by clear and conspicuous notice delivered to the resident online when the resident is connected to the online account from an IP address or online location from which the company knows the resident customarily accesses the account.