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.
SPONSORED BY
8/3/2017
09:00 AM
Michael Koyfman
Michael Koyfman
Partner Perspectives
Connect Directly
Twitter
LinkedIn
RSS
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
mklinchin
100%
0%
mklinchin,
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.
For Cybersecurity to Be Proactive, Terrains Must Be Mapped
Craig Harber, Chief Technology Officer at Fidelis Cybersecurity,  10/8/2019
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17545
PUBLISHED: 2019-10-14
GDAL through 3.0.1 has a poolDestroy double free in OGRExpatRealloc in ogr/ogr_expat.cpp when the 10MB threshold is exceeded.
CVE-2019-17546
PUBLISHED: 2019-10-14
tif_getimage.c in LibTIFF through 4.0.10, as used in GDAL through 3.0.1 and other products, has an integer overflow that potentially causes a heap-based buffer overflow via a crafted RGBA image, related to a "Negative-size-param" condition.
CVE-2019-17547
PUBLISHED: 2019-10-14
In ImageMagick before 7.0.8-62, TraceBezier in MagickCore/draw.c has a use-after-free.
CVE-2019-17501
PUBLISHED: 2019-10-14
Centreon 19.04 allows attackers to execute arbitrary OS commands via the Command Line field of main.php?p=60807&type=4 (aka the Configuration > Commands > Discovery screen).
CVE-2019-17539
PUBLISHED: 2019-10-14
In FFmpeg before 4.2, avcodec_open2 in libavcodec/utils.c allows a NULL pointer dereference and possibly unspecified other impact when there is no valid close function pointer.