Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
09:00 AM
Michael Koyfman
Michael Koyfman
Partner Perspectives
Connect Directly

Fight 'Credential Stuffing' with a New Approach to Authorization

Token-based authorization that lets users prove their identity through Facebook, Google, or Microsoft credentials can dramatically reduce your attack surface and give enterprises a single point of control.

The year 2016 has been called "the year of stolen credentials," and with good reason. Between the massive breaches at Yahoo, LinkedIn, Tumblr, Twitter, and Dropbox, 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. What’s more, these stolen credentials are readily available for sale on the dark Web to anyone willing to pay the price.

What Is Credential Stuffing?
With this glut of stolen credentials, we’re seeing a rise in what are known as “credential stuffing” attacks. Attackers use automated tools to test stolen credentials 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. 

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 a 2015 estimate) 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 own 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 it, applications are especially vulnerable because they have only one layer of protection and are therefore easily compromised using stolen credentials alone.

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 typically 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.  

Methods for Dealing with Credential Stuffing
There’s no shortage of advice online about how you can help mitigate credential stuffing attacks. Of course, it makes sense to 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. 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 using managed access tokens. As a user, you’ve already proven your identity (authentication) using your Facebook, Google, or Microsoft credentials, so whatever application you are 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, the user is granted access; if it doesn’t, the user is denied access; It’s that simple. Because token-enabled applications don’t even use credentials to authorize users, they can reduce the incidence of credential stuffing attacks by drastically reducing the attack surface area.

A more 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. 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 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.

Get the latest application threat intelligence from F5 Labs.

Michael Koyfman is a Sr. Global Security Solution Architect with F5 Networks with a 12 year tenure with the company.  He is focused on the entire portfolio of F5 Security products, and over the last 7 years has been a key contributor to implementation, strategy, and ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
8/3/2017 | 2:34:51 PM
Let's celebrate de-centralization
It is tempting to designate few dedicated authorities to handle some aspects of the social life (like authentication) but it is not a good trend. It would definitely simplify things and whould probably add more security. However, it would also promote authoritarizm whether based on a foul thinking or even unintentional one. One of the powers of the Internet is in its ability to de-centralize influences of few stong entities whether they would be states or large enterprises. I beleive that we need to move in this direction.

I think that complex modern technology should become available to everybody, large or small, whoever would want to use it to handle its own data and its own user lists; deciding for itslef whether to disclose it to the supreme authority or not - as long as it is legal. I understand that it is much harder to ensure security in such a world. This is a classic security vs privacy question. The danger of fighting monsters is to become one of those monsters. But I think that we all are moving in the right direction so the situation is not that dire.
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 attempts to delete malicious files (such as .php) form the uploaded archive via the "Import Settings" feature, after its extraction. However, the extracted folders are not checked and it is possible to upload a zip which contained a directory w...
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 attempts to remove potential malicious files from the extracted archive uploaded via the 'Import Settings' feature, however this is not sufficient to protect against RCE as a race condition can be achieved in between the moment the file is extracted on t...
PUBLISHED: 2021-06-21
The Autoptimize WordPress plugin before 2.7.8 does not check for malicious files such as .html in the archive uploaded via the 'Import Settings' feature. As a result, it is possible for a high privilege user to upload a malicious file containing JavaScript code inside an archive which will execute w...
PUBLISHED: 2021-06-21
The Comments Like Dislike WordPress plugin before 1.1.4 allows users to like/dislike posted comments, however does not prevent them from replaying the AJAX request to add a like. This allows any user (even unauthenticated) to add unlimited like/dislike to any comment. The plugin appears to have some...
PUBLISHED: 2021-06-21
The WP Google Maps WordPress plugin before 8.1.12 did not sanitise, validate of escape the Map Name when output in the Map List of the admin dashboard, leading to an authenticated Stored Cross-Site Scripting issue