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.
Devastating Cyberattack on Email Provider Destroys 18 Years of Data
Jai Vijayan, Freelance writer,  2/12/2019
Up to 100,000 Reported Affected in Landmark White Data Breach
Kelly Sheridan, Staff Editor, Dark Reading,  2/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8358
PUBLISHED: 2019-02-16
In Hiawatha before 10.8.4, a remote attacker is able to do directory traversal if AllowDotFiles is enabled.
CVE-2019-8354
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.
CVE-2019-8355
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.
CVE-2019-8356
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.
CVE-2019-8357
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.