Credential Stuffing: Minimizing the Threat

By Robin Chan

To reduce the possibility of credential stuffing attacks and account takeovers (ATO), enterprises must implement security essentials such as strong password policies and multi-factor authentication (MFA), as well as strike a balance between user experience and security. Credential stuffing attacks can be difficult to distinguish from regular user traffic, allowing security measures such as rate limiting to be rendered ineffective, especially with services that see high traffic volumes on a daily basis. To detect anomalies, traffic must be baselined and analyzed, on a per-user basis. Furthermore, you’ll need a solution that can tell the difference between user errors or changes in behavior caused by API modification and malicious activity, such as an attacker looking for business logic flaws or manipulating APIs. Once a system identifies potential credential stuffing attacks, it must quickly alert SecOps teams for fast response, given them the context they need to thwart credential stuffing attacks promptly and effectively.

How to Defend Against Credential Stuffing

Credential stuffing can be avoided by using the following strategies and tools:

Use Multi-Factor Authentication (MFA)

First and foremost, implementing Multi-Factor Authentication is a critical component in defending against credential stuffing attacks as credential stuffing is based on automated scripts and technologies that make it difficult to provide additional authentication factors, such as authentication tokens sent by email or SMS. According to Microsoft’s research, MFA would have prevented 99.9% of account breaches. It’s crucial to remember that attackers will try to break into MFA systems, thus organizations must safeguard their MFA systems from brute-force attempts. If requiring MFA for all users is not practical, it should at least be made mandatory for all administrators.

Implement Behavioral Analytics

If an organization integrates baselines of usual user behavior and traffic patterns, credential stuffing may be identified more readily and quickly. By automatically building and maintaining baselines of anticipated behavior, API security systems “can identify any activity that deviates from the baseline, including the abnormal movement of data and the attempted manipulation of tokens, user IDs, or API parameters.” 

Avoid Using Email Addresses as User IDs

Users that use the same username or account ID across many services are more vulnerable to credential stuffing attempts. The risk increases when the ID is an email address, which attackers may easily get or guess. By requiring unique usernames, you may reduce the danger of credential stuffing attacks.

Implement CAPTCHA

By requiring users to prove that they are human by accomplishing tasks that are simple for humans but challenging for computer scripts, such as identifying specific items in a set of photographs or recognizing distorted characters, CAPTCHA can reduce the efficacy of credential stuffing assaults. CAPTCHA may be readily added to an app or website – however, hackers who utilize headless browsers or CAPTCHA solver services can simply get around it. The poor user experience often outweighs the limited security given by CAPTCHA. However, one can opt to require the user to answer a CAPTCHA when the login is suspicious, such as many unsuccessful login attempts or logins from a different location.

Implement IP Address Deny lists

Due to the possibility that attackers may be working from a limited pool of IP addresses, recognizing, and banning IPs that attempt to log into several accounts can help prevent credential stuffing. On the other hand, detecting malicious IP addresses can be difficult. Public IP blacklists are frequently out of date, and attackers will change their IP addresses on a regular basis. The problem is made worse by the availability of cheap and plentiful cloud computing resources. Attackers will spin up new instances of computers or use serverless computing to continue credential stuffing attacks, significantly increasing the complexity hurdle for security teams trying to maintain deny lists.

Deploy Device Fingerprinting and User Profiling

Device fingerprinting combines a device’s distinct characteristics, such as its operating system, web browser type and version, language preferences, and IP address. Another technique to profile people is to look at how they use their devices and applications, as well as any settings or changes they make, such as screen resolution, installed fonts, and installed browser plugins. When employing device fingerprinting as a defense against credential stuffing, one expects that a device identified with particular characteristics one day will be the same device detected with those same characteristics the next.

The disadvantages of fingerprinting and profiling include the demand for reverse-engineerable and evadable client-side code, as well as the fact that these safeguards do not apply to machine-to-machine or direct API interactions. You can use the  fingerprintjs2 JavaScript library to do client-side fingerprinting.

Block Headless Browsers

A headless browser is a web browser that lacks a graphical user interface (GUI). A headless browser is a word that is frequently used to describe scripts or automation tools. Among development, QA, and business teams, headless browsers are a common test tool for automation and process automation. They’re seldom used for real web surfing, and they sometimes don’t have a JavaScript engine capable of running client-side code. Blocking headless browsers is a viable mitigation method based on an organization’s use of automated IT processes, but it should not be relied on as a credential stuffing protection. Attackers who are determined will use more powerful headless browser technologies or change scripts to imitate regular browser behavior to get around such simple defenses.

Rate-Limit Non-Residential Traffic Sources

Attackers might launch attacks from countries where your company doesn’t normally do business. Because they are home to severe threat actors, countries like China, North Korea, and Russia may be high on security teams’ priority lists. You can set more restrictive rate limitations for those areas’ IP address ranges to help reduce the risk of credential stuffing, but most attackers will likely use other data centers and cloud service providers to move to less limited IP address space. Establishing regional rate limitations may have an impact on both real users and the business if you’re a worldwide organization.

Identifying Leaked Passwords and Auditing

When a user creates a new password on the app, it can be compared to a list of known weak passwords as well as passwords that have been hacked in the past. The most well-known public service for password testing is Pwned Passwords. You may use the API to test possibly weak passwords or host your own copy of the software. Pwned Passwords use a k-Anonymity model, which allows a password to be searched for using a partial hash in order to protect the original password’s value. 

After you’ve installed the tools and policies to minimize credential stuffing attacks, the next step is to do security testing and audits against the security configuration you’ve put in place. Please make sure you have the proper permission and documentation prepared before performing any security testing!

Robin Chan is a 3rd-year student at Fanshawe College working towards an Ontario College Advanced Diploma in Cyber Security. When he’s not working or in school, he’s learning about various technologies and evolving IT threats, tinkering with tech, playing video games, writing for Bora and watching Studio Ghibli films.