2016 has been called “the year of stolen credentials,” and with good reason. Between the massive breaches at Yahoo, LinkedIn, MySpace, Tumblr,1 Twitter,2 and Dropbox,3 just to name a few, it’s estimated that over 2 billion records were stolen. Although attackers steal all kinds of data, a vast majority of what’s stolen are user credentials, and they’re being put to bad use. The 2017 Verizon Data Breach Investigation Report found that 81% of hacking-related breaches leveraged stolen and/or weak passwords.4 What’s more, these stolen credentials are readily available for sale on the dark Web to anyone willing to pay the price.5
What is Credential Stuffing?
With this glut of stolen credentials, we’re seeing a rise in what are known as “credential stuffing” attacks. What are these attacks and how do they work? Attackers obtain large volumes of user credentials stolen from one website (like those named above) and use automated tools to test them in the login fields of other, targeted websites (hence, the name credential “stuffing”). When a username/password pair grants the attackers access, they take over that account for fraudulent purposes. By some estimates, as many as 90% of all login attempts on web-based applications at Fortune 100 firms are actually credential stuffing attempts rather than legitimate logins.6
Why Credential Stuffing is a Serious Threat to all Organizations
Often organizations think that they’re “safe” if their own data has not been stolen, but that’s simply not true. One of the reasons credential stuffing is so wildly successful is that many people (73%, by one estimate7) reuse their passwords for multiple applications—both personal and work-related. This significantly increases the attack surface and the risk to everyone, because if attackers can gain access to one application with stolen user credentials, there’s a good chance those credentials will work with another application, and another, and another…
This is why credential stuffing is such a critical threat to organizations. Many enterprises have multiple web-based applications exposed on the Internet that are protected by nothing more than—you guessed it—login credentials. So, even if your internal systems have not been breached, it’s conceivable that your external applications, whether you have 5 or 500 of them, will be targeted by attackers using stolen credentials. Breach or not, your applications are potentially at risk. This problem is compounded by the fact that few applications (yet) support multi-factor authentication (MFA). Without MFA, applications are especially vulnerable because they have only one layer of protection and are therefore easily compromised using stolen credentials alone.
APIs Are at Risk, Too
For many organizations, the attack surface is even broader still because their application programming interfaces (APIs) are also vulnerable. Typically, APIs are the set of clearly defined methods of communication between various software components. Although there are several methods for authenticating APIs, it’s surprising how many are still authenticated using only login credentials.
Consider, too, that the authentication and authorization process is usually separate for each application or API, so organizations must monitor and protect each application independently. It’s kind of like trying to manage a border wall built in 50 separate sections by 50 different contractors, each section with its own gate, varying levels of staff and monitoring, and unique admittance policies.
Without any coordination or consistency across those 50 sections, each gate is a penetrable target. The potential exists for thousands of people using stolen credentials to pass through those 50 gates. Now consider the nightmare scenario in which millions of people’s passports have been stolen and handed out indiscriminately to a bunch of bad guys trying to enter through those gates. That’s fundamentally what credential stuffing is like—only it’s automated, so it’s far more dangerous. This kind of approach to border control—which is essentially the same function that authorization solutions provide to web-based applications—can quickly become a security and management nightmare.
Semi-Effective Methods for Dealing with Credential Stuffing
So, what can you do about it? There’s no shortage of advice online about how you can help mitigate credential stuffing attacks. Of course, it makes sense to leverage perimeter defense technologies (like a WAF) that block traffic from known bad sources, train users not to use duplicate passwords, implement multi-factor authentication wherever possible, and strengthen your access policies, for example, by forcing password resets after significant breaches occur. It’s all good advice, but it’s not sufficient. It bypasses the heart of the problem, which is that our approach to authorization is quickly becoming outdated. It’s time we considered the feasibility of a token-based authorization model.
Moving to a Token-Based Authorization Approach
What is token-based authorization? In simplest terms, it’s a framework that enables a user to access an application without having to provide their credentials to that application itself. Instead, the user is granted access through the use of managed access tokens (not to be confused with physical 2-factor authorization tokens that people possess). In fact, you are probably using such an approach in your daily life. Any application that is connected to Facebook, Google, or Microsoft (to name just a few) and allows you to log in using those credentials is using a token-based authorization mechanism and standard frameworks like OAuth 2.0 to make that possible. As a user, you’ve already proven your identity (authentication) using your Facebook, Google, or Microsoft credentials, so whatever application you’re trying to access isn’t looking for you to supply your credentials again. Instead, as an OAuth-enabled application, it’s only looking for a token to authorize your access. If it receives a valid one, you’re granted access; if it doesn’t, you’re denied access, it’s that simple.
Because token-enabled applications don’t even use credentials to authorize users, they can cut the incidence of credential stuffing attacks by drastically reducing the attack surface area. Tokens help shrink the attack surface because they’re issued to a user for a specific application. So, a token that grants a user access to Netflix, for example, could not also be used to access Spotify. In addition, tokens typically have a very short expiration time, so even if a token were to get stolen via a man-in-the-something attack, the potential damage an attacker could wreak would be limited in both time and scope of access. In the token-based scenario such as OAuth, any credential stuffing attack would need to be directed only at the single resource—the Authorization Server.
Although OAuth has been around for several years and many apps support it, it’s downside is that, as an authorization framework, it is not very secure. In other words, while it serves the purpose of authorizing access, it does not inherently protect itself, and each implementation needs to be vetted. Because OAuth doesn’t provide specifics on how it should be implemented, every implementation may be slightly different and would also require its own security verification to ensure it is safe from exploits.8 It also requires modifying applications to make them OAuth-enabled. This may be far easier for some applications (newer ones, for instance) than for legacy applications.
A more progressive and practical evolution of this token-enabled model would be to avoid rewriting applications altogether. Instead, implement an authorization gateway that supports OAuth and can translate OAuth authorization back to the application, either via its native authentication method or a less intrusive change that could be simpler to accomplish. In doing so, you essentially move all authorization away from being handled at the application/API level and centralize this service for all applications. In our border wall analogy, it would be like closing up 49 of the border wall gates in favor of one, centralized gate through which all visitors would pass. This would dramatically reduce the credential stuffing attack surface and gives you a single point of control for all authorization.
