Do you ever use the same username and password on more than one website? Most people sometimes do, and thereby put themselves at risk for “credential stuffing.” That’s what it’s called when hackers take usernames and passwords that were compromised in a past breach of Site A, and use them to launch a new invasion of user accounts on Site B.
Now the U.S. Federal Trade Commission has brought its first–ever enforcement case in this area. The target? Not a hacker, but TaxSlayer LLC, aka Site B. TaxSlayer is an online tax preparation service that fell victim to a credential-stuffing attack.
The FTC’s message is loud and clear: If customer data was put at risk by credential stuffing, then being the innocent corporate victim is no defense to an enforcement case. Rather, in the FTC’s view companies holding sensitive customer information should be taking affirmative action to reduce the risk of credential stuffing. In particular, the TaxSlayer case strengthens a trend toward making multi-factor authentication—the use of a second layer of entry credentials, like a text message code, in addition to a password—all but a legal requirement for financial institutions.
How Credential Stuffing Works
Let’s say Harry Hacker breaks into the network of OnlineRetailer.com. Once in, Harry obtains a million customers’ username and password combinations. Jane Jones, for example, accesses OnlineRetailer.com with the username “firstname.lastname@example.org” and the password “janespassword.” And now Harry Hacker knows it.
Next Harry begins to look for other websites to attack. Or, perhaps, he markets the stolen credentials on the “dark web”—the shadowy corner of the Internet where bad guys traffic in black–market data. Those username-and-password combinations that Jane Jones and a million others use at OnlineRetailer.com are now circulating among cybercriminals.
Next, Harry Hacker (or Hacker #2, having bought the compromised credentials on the dark web) launches a new round of attacks. He takes all those stolen credentials from OnlineRetailer.com, and uses an automated tool to enter the credentials en masse at OnlineBank.com, OnlineBroker.com, and OnlineTravel.com. Jane Jones uses the same username and password at all four sites. The hacker now has access to her accounts at all four. That includes access to her credit card numbers, account numbers, and other personal details Jane has stored there for convenience.
Notably, the hacker has not gained general access to any of these companies’ networks. Nor do any of the companies involved necessarily even have any clue that the attacks are even happening. On the contrary, to them, it simply looks like Jane Jones—a known user—has entered her legitimate credentials.
Credential stuffers are taking advantage of two unhappy trends. First, upwards of 80% of people are estimated to reuse credentials across at least some of their online accounts. Second, as more companies fall victim to data breaches, the pool of compromised credentials gets bigger. The upshot is that with each new breach, credential-stuffing attacks may become exponentially more effective. Published reports indicate that high-profile companies, such as Pinterest Inc, and Groupon Inc., are among the many that have suffered credential-stuffing attacks.
The TaxSlayer Investigation and Settlement
As with many FTC enforcement matters, the TaxSlayer complaint and settlement (in the form of a consent order) were publicly released on the same day. The publicly available “facts” therefore are as set forth by the FTC in its rather bare-bones pleading.
The complaint explains that TaxSlayer operated a browser-based and mobile tax return service. Users were required to create accounts and to input a slew of personal information. TaxSlayer therefore found itself holding details about its customers ranging from their Social Security numbers to their bank account and credit card numbers to their marital status, dependents, financial assets, and health insurance.
From Oct. 10 to Dec. 21, 2015, TaxSlayer suffered a credential-stuffing attack. (The FTC actually uses the less fun term “list validation attack.”) The cybercriminals were able to access nearly 9,000 TaxSlayer customers’ accounts. The bad guys filed an unknown number of fraudulent returns, directing refunds to themselves instead of to the actual taxpayers. The attack ended when TaxSlayer imposed a multifactor authentication requirement. The FTC specifically notes that TaxSlayer was unaware of the attack until it received a user complaint in January 2016. The complaint itemizes a long list of harms suffered by consumers whose tax accounts are compromised.
The legal challenge for the FTC was that no applicable statute, regulation or caselaw specifically imposed any duty on TaxSlayer to detect or prevent credential stuffing. The FTC relied instead on a more general theory: namely, that TaxSlayer had failed to meet the Privacy Rule and the Safeguards Rule of the Gramm–Leach–Bliley Act (GLBA). The GLBA is a data privacy statute that applies to “financial institutions,” meaning all businesses that are “significantly engaged” in “financial activities.” A company may meet this definition even if “financial activities” are not its primary purpose. For example, a car dealership offering car loans may be covered. While TaxSlayer lacked the traditional trappings of, say, a bank or an investment adviser, the FTC contended that its tax return activities made it subject to the GLBA.
The FTC alleged that TaxSlayer “failed to provide a clear and conspicuous initial privacy notice” and “failed to deliver the initial privacy notice so that each customer could reasonably be expected to receive actual notice” in violation of the Privacy Rule and Reg P. One might ask—so what? Compliance with the Privacy Rule or Reg P is certainly an important legal mandate, but here it would not have stopped the credential-stuffing attack.
The Safeguards Rule has more teeth, and here’s where TaxSlayer perhaps felt more bite. This rule requires covered institutions to have a “comprehensive written information security program.” Companies are required to conduct security assessments and “design and implement information safeguards to control the risks” identified during those assessments. § 314.4(c). TaxSlayer was alleged to be in violation of this rule because it “failed to have a written information security program until November 2015,” and “failed to conduct a risk assessment, which would have identified reasonably foreseeable internal and external risks to the security.”
Notably, the FTC alleged that credential-stuffing attacks have become reasonably foreseeable. On that hook, the FTC essentially hung a legal mandate to detect and prevent such attacks—translating the general requirements of the Safeguards Rule into a de facto set of highly specific requirements. The FTC ticked off a list of alleged failures by TaxSlayer that the complaint said violated the Safeguards Rule:
- A weak password requirement, the only mandate being that the password be 8 to 16 characters.
- A lack of “risk–based authentication methods”, e.g., multi-factor authentication. As noted, this is when, for example, your bank texts you a temporary access code which you must enter to get to your account online, the code changing every time you log in.
- Not telling customers when someone had made a material change to their address, password or security question.
- Not validating email addresses at account creation.
- Not using “readily–available tools” to prevent attempted credential stuffing. The FTC didn’t say what tools it had in mind, but security experts promote the use of several, such as IP blacklisting—a tool that spots and blocks any IP address attempting to generate a large number of login attempts in a short period of time.
Each of these steps would certainly be endorsed by security experts as a best practice for many companies in many contexts. The TaxSlayer case highlights that the FTC effectively regards these best practices as having the force of law. Put another way: any financial institution that is covered by GLBA, holds sensitive customer information, and is not utilizing these tools may face an uphill battle if they suffer a future credential-stuffing attack and the FTC comes calling.
The FTC’s press release accompanying the settlement strongly suggested that, among these now de facto requirements, multi-factor authentication is first among equals. Tom Pahl, acting director of the FTC’s Bureau of Consumer Protection, said the case “demonstrates the importance of password protection … Hackers took advantage of people who re-used passwords from other sites, and the attack ended when TaxSlayer eventually required people to use multi–factor authentication.” (emphasis added). The FTC published a blog post about the case entitled “TaxSlayer: File this one under authentication.”
The consent order agreed to by TaxSlayer bolstered the FTC’s position in a number of ways. TaxSlayer was placed under a 20-year requirement to conduct risk assessments, tailor its information security program to the results, and certify the effectiveness of its information security program. TaxSlayer specifically undertook to comply with GLBA, including the Privacy Rule and the Safeguards Rule. While this legal requirement would apply in the absence of a consent order, the order subjects TaxSlayer to contempt risk if it does not comply with the law. The words “multi-factor authentication” are not found in the consent order, but they might as well be. TaxSlayer must comply with the Safeguards Rule, and the FTC clearly regards multi-factor authentication as part of that compliance obligation.
How Multi-factor Authentication Deters Credential Stuffing
There are many ways that companies might prevent or limit credential-stuffing attacks on their platforms. For example, as suggested by the FTC’s ticklist in the TaxSlayer complaint, companies can:
- Ask an additional security question when a user logs in from a new device.
- Require strong, complex passwords and make users change them at regular intervals—reducing the odds that the user will adopt the same credentials across multiple sites.
- Limit the number of unsuccessful log-in attempts from a particular device or IP address within a given time window. (Note that clever criminals may be able to pace their automated attacks to defeat such limits.)
- Require manual entry of additional information, such as the last four digits of a previously obtained credit card or Social Security number, prior to major actions such as purchases or submitting tax returns.
Among these, the FTC has chosen to highlight multi-factor authentication. Multi-factor authentication is the process by which the user’s identity is verified by drawing on the functionality of another device. As noted, this often takes the form of a temporary code being sent to a second device. The user then enters this code to log into the platform. The code can be delivered via text message or draw upon software designed for the purpose, such as RSA Security LLC’s SecureID. Other forms exist as well. For example, a flash drive might serve as a key, only allowing a log-in for that user from devices with the flash drive inserted.
The principal feature of multi-factor authentication is that, in order for the user to log in or to perform certain sensitive functions, the user must have access to a device or application separate and apart from the relevant platform. This prevents cybercriminals from accessing a user’s account even if they possess the correct initial login credentials.
The TaxSlayer settlement is not the first time the FTC has beaten the drum for multi-factor authentication. In April 2016, the FTC published “Mobile Health App Developers: FTC Best Practices.” The FTC recommended that developers consider authentication carefully when designing an application: “If risks are substantial, consider multi–factor authentication—for example, requiring the use of a password and a separate code sent via another channel, such as an email or text.” In June of 2016, the FTC issued a guide targeted to consumers addressing what to do in the event of a password breach. The first recommendation: “use multi–factor authentication, when it’s available.”
Later in 2016, the FTC expanded its more targeted recommendations to businesses generally. When issuing the 2016 update to its “Protecting Personal Information: A Guide for Business,” the FTCadded recommendations on using multi-factor authentication and noted that a key point in the revised guide was that developers should “consider using multi-factor authentication, such as requiring the use of a password and a code sent by different methods.” A post on the FTC’s business blog in August 2017 reiterated: “to combat credential-stuffing attacks and other online assaults, companies should combine multiple authentication techniques for accounts with access to sensitive data.” (emphasis added).
The first FTC investigation and settlement in which the FTC clearly labeled the lack of multi-factor authentication an issue was announced on Aug. 15, 2017. The FTC alleged inappropriate data handling practices at the ridesharing company Uber Technologies Inc.—both undue access to riders’ personal data by Uber’s own employees and an external breach facilitated by an Uber employee publicly posting the login key online. The focus of the accompanying press release was on the lack of measures taken to ensure rider data security. The FTC noted: “Uber did not require engineers and programmers to use distinct access keys to access personal information stored in the cloud. Instead, Uber allowed them to use a single key that gave them full administrative access to all the data, and did not require multi-factor authentication for accessing the data.” (emphasis added).
While the Uber settlement itself did not explicitly call for the implementation of multi-factor authentication, the accompanying FTC press release noted multi-factor authentication is an effective privacy protection tool. The settlement agreement broadly directed Uber to initiate “the design and implementation of reasonable controls and procedures to address such risks and regular testing or monitoring of the effectiveness of those controls and procedures.” The Uber case makes clear that multi-factor authentication may be seen as required not just for external access, but as part of a company’s internal access controls as well.
The trend toward multi-factor authentication has been strongly reinforced at the state level. Last year, New York’s Department of Financial Services adopted a first-in-the-nation cybersecurity regulation applicable to “Covered Entities”—banks, insurance companies and other firms licensed by DFS, which is to say thousands of the largest financial institutions in the country and the world. Over time, Covered Entities must implement multi-factor authentication “for any individual accessing the Covered Entity’s internal networks from an external network,” unless the chief information security officer specifically approves the use of “reasonably equivalent or more secure controls.” More generally, Covered Entities are required to use “effective controls”—which, DFS specifically notes, “may include Multifactor Authentication”—to “protect against unauthorized access” to information and systems. 23 NYCRR § 500.12.
TaxSlayer is the first word from the enforcement community on credential stuffing, and not the last. It remains the case that there is no explicit legal mandate to prevent and detect credential stuffing, whether under the name “list validation attacks” or any other. Companies whose conduct in this area is called into question will always have case-specific defenses to offer as to why their cybersecurity program, as a whole, was reasonably configured to deal with foreseeable risks.
Nonetheless, if it wasn’t clear before, it is after TaxSlayer: Companies that fail to consider the risks of credential stuffing, and to implement mitigating controls, do so at their peril. Companies that fail to use multi-factor authentication to protect sensitive data do so at their particular peril. The precise legal hook relied upon by privacy enforcers will always vary from case to case, but the enforcement community’s commitment to these principles is here to stay.
To contact the editor responsible for this story: Donald Aplin at email@example.com