Credential Stuffing Explained: What is it? How to detect? How to prevent it?
The billions of login credentials available on the dark web make it easy for cybercriminals to steal login credentials. It has been widely reported that automated access data — the plug-in attack that has found its way onto the internet — is hitting systems such as credit cards, bank accounts, and credit card numbers.
Credential Stuffing is a technique that involves an automatic injection attack to access online services with stolen credentials. In an attack on the login data, fraudsters use it to access consumer accounts to make fraudulent purchases, carry out phishing attacks and steal information and money.
This attack method is facilitated by a range of off-the-shelf tools which are easily available, making it unsophisticated and relatively straightforward.
Commonly used tools include Sentry MBA, Account Hitman, Vertex, and Apex. To launch an attack, an attacker simply needs their tool of choice, a configuration file for the website to be attacked, and a list of username/password combinations to test against the site. Log-in attempts are typically directed through one or more proxies to hide the source of the attack. The software is set up to automatically insert the credentials from the username/password list into the corresponding fields contained within the GET or POST requests.
To carry out a large-scale attack on the credentials, malicious hackers use bots that fake different IP addresses and can automatically enter multiple accounts in parallel.
The credential stuffing uses known password-login-credentials combinations to make the process successful, not the references that make it successful. Such attacks take advantage of this behavior, relying on people to use matching passwords for multiple online accounts. While using the same username and password combinations on multiple websites increases the credential stuffing attacks, single-sign-on (SSO) minimizes the number of credentials — thwarted attacks because users must log in with only one set of credentials and then log in to other accounts.
While credentialing is an automated process used in botnets, login systems for websites can add another layer of security by recognizing which platform the login request originates from. Hackers can then create automated scripts and use configurable credentials — and use software to systematically test whether the stolen credentials successfully log in to the landing page.
Credential stuffing is categorized as a subclass of brute force attacks by OWASP. Yet credential stuffing is somewhat different from regular brute force attacks. Attacks using brute forces aim to formulate passwords without context, often using characters arbitrarily together with password recommendations. The credentials use the exposed info, which significantly decreases the amount of potential accurate responses.
Unlike password spraying, “credential stuffing” is a brutal attack defined as a technique for taking over accounts that involves automated password permutations. Simply put, cybercriminals acquire stolen usernames and passwords in any way, usually on the darknet, and then use botnets or other automation tools to gain unauthorized access to user accounts with the stolen login credentials. In short, filling in credentials is an automatic injection of credentials to gain unauthorized control over a user’s account, such as credentials. Attacks on access authorization can use a botnet that uses automated scripts to try to access accounts with legitimate credentials that allow the hijacking of at least one account.
What is the difference between credential stuffing, brute force attacks, and password spraying?
· Brute force attacks: From a list of common or weak usernames/passwords pairs are used to hack into an account.
· Credential stuffing: Leaked and compromised username/password pairs are used to hack into different accounts.
· Password spraying: The same password with different usernames is used to hack into different accounts.
To detect an attack on the credentials, organizations must be aware of the number of failed logins attempts and the duration of each login attempt. Attacks with credentials create a list of credentials up to a list of valid accounts that prepare them for further attacks.
Although the attacks with credentials are due to a human problem, there are a number of educational and technological solutions that organizations can implement to reduce the risk of falsification.
Credit card completion is particularly dangerous when consumers use the same usernames and password combinations for multiple accounts, giving a cyber thief access to all of these accounts in one go. Password reuse is a key factor in attacks on access data and this practice should be strongly discouraged at work or at home. The best way to protect your account details from fraudsters is to stop using the same passwords for multiple accounts.
Following indicators can give an idea if credential stuffing attack is taking a place;
· Multiple failed attempted logins across multiple accounts. The tools can be configured to use a new IP address each time a set of credentials is attempted against a user account. Previous credential stuffing attacks indicate a considerable variation in the number of different IPs used to launch an attack — from one up to tens of thousands.
· Higher than usual volumes of foreign IPs, or anomalies in browser activity.
· Patterns in log-in attempts indicate the use of automation (this could be authentication attempts to an API or log-ins to a website portal).
An important factor in creating credentials is the fact that users reuse passwords for more than one application. The success of a credential stuffing attack depends on whether the user has poor password hygiene.
Since a key function of the login data is to detect successful logins from multiple websites, make sure that usernames are generated that are unique to each website, and avoid using email addresses as user IDs. A significant number of websites use an email address as their username, so make it clear that most users will have difficulty using a single email address for all their accounts. Since many of the available login lists contain only e-mail addresses, it is difficult for an attacker to obtain a valid username-password pair — by filling in credentials.
What Can Be Done? OWASP Credential Stuffing Prevention Cheat Sheet
Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible; however, depending on the audience of the application, it may not be practical or feasible to enforce the use of MFA.
In order to balance security and usability, multi-factor authentication can be combined with other techniques to require for 2nd factor only in specific circumstances where there is reason to suspect that the login attempt may not be legitimate, such as a login form:
- A new browser/device or IP address.
- An unusual country or location.
- Specific countries that are considered untrusted.
- An IP address that appears on known blocklists.
- An IP address that has tried to log in to multiple accounts.
- A login attempt that appears to be scripted rather than manual.
Additionally, for enterprise applications, known trusted IP ranges could be added to an allow list so that MFA is not required when users connect from these ranges.
Where it is not possible to implement MFA, there are many alternative defenses that can be used to protect against credential stuffing and password spraying. In isolation none of these are as effective as MFA, however, if multiple defenses are implemented in a layered approach, they can provide a reasonable degree of protection. In many cases, these mechanisms will also protect against brute-force or password spraying attacks.
Where an application has multiple user roles, it may be appropriate to implement different defenses for different roles. For example, it may not be feasible to enforce MFA for all users, but it should be possible to require that all administrators use it.
Secondary Passwords, PINs, and Security Questions
As well as requiring a user to enter their password when authenticating, they can also be prompted to provide additional security information such as:
- A PIN
- Specific characters from a secondary password or memorable word
- Answers to security questions
It must be emphasized that this does not constitute multi-factor authentication (as both factors are the same — something you know). However, it can still provide a useful layer of protection against both credential stuffing and password spraying where proper MFA can’t be implemented.
Requiring a user to solve a CAPTCHA for each login attempt can help to prevent automated login attempts, which would significantly slow down a credential stuffing or password spraying attack. However, CAPTCHAs are not perfect, and in many cases, tools exist that can be used to break them with a reasonably high success rate.
To improve usability, it may be desirable to only require the user to solve a CAPTCHA when the login request is considered suspicious, using the same criteria discussed above.
Less sophisticated attacks will often use a relatively small number of IP addresses, which can be block-listed after a number of failed login attempts. These failures should be tracked separately from the per-user failures, which are intended to protect against brute-force attacks. The blocklist should be temporary, in order to reduce the likelihood of permanently blocking legitimate users.
Additionally, there are publicly available block lists of known bad IP addresses which are collected by websites such as AbuseIPDB based on abuse reports from users.
Consider storing the last IP address which successfully logged in to each account, and if this IP address is added to a block list, then taking appropriate action such as locking the account and notifying the user, as it likely that their account has been compromised.
Aside from the IP address, there are a number of different factors that can be used to attempt to fingerprint a device. Some of these can be obtained passively by the server from the HTTP headers (particularly the “User-Agent” header), including:
- Operating system
- Screen resolution
- Installed fonts
- Installed browser plugins
Using these various attributes, it is possible to create a fingerprint of the device. This fingerprint can then be matched against any browser attempting to login into the account, and if it doesn’t match then the user can be prompted for additional authentication. Many users will have multiple devices or browsers that they use, so it is not practical to block attempts that do not match the existing fingerprints.
It should be noted that as all this information is provided by the client, it can potentially be spoofed by an attacker. In some cases spoofing these attributes is trivial (such as the “User-Agent”) header, but in other cases, it may be more difficult to modify these attributes.
Require Unpredictable Usernames
Credential stuffing attacks rely on not just the re-use of passwords between multiple sites, but also the re-use of usernames. A significant number of websites use the email address as the username, and as most users will have a single email address they use for all their accounts, this makes the combination of an email address and password very effective for credential stuffing attacks.
Requiring users to create their own usernames when registering on the website makes it harder for an attacker to obtain valid usernames and password pairs for credential stuffing, as many of the available credentials lists only include email addresses. Providing the user with a generated username can provide a higher degree of protection (as users are likely to choose the same username on most websites), but is user-friendly. Additionally, care needs to be taken to ensure that the generated username is not predictable (such as being based on the user’s full name, or sequential numeric IDs), as this could make enumerating valid usernames for a password spraying attack easier.
Defense in Depth
The following mechanisms are not sufficient to prevent credential stuffing or password spraying attacks; however, they can be used to make the attacks more time-consuming or technically difficult to implement. This can be useful to defend against opportunistic attackers, who use off-the-shelf tools and are likely to be discouraged by any technical barriers, but will not be sufficient against a more targeted attack.
Multi-Step Login Processes
The majority of off-the-shelf tools are designed for a single-step login process, where the credentials are POSTed to the server, and the response indicates whether or not the login attempt was successful. By adding additional steps to this process, such as requiring the username and password to be entered sequentially, or requiring that the user first obtains a random CSRF Token before they can log in, this makes the attack slightly more difficult to perform and doubles the number of requests that the attacker must make.
Identifying Leaked Passwords
When a user sets a new password on the application, as well as checking it against a list of known weak passwords, it can also be checked against passwords that have previously been breached. The most well-known public service for this is Pwned Passwords. You can host a copy of the application yourself, or use the API.
In order to protect the value of the source password being searched for, Pwned Passwords implements a k-Anonymity model that allows a password to be searched for by partial hash. This allows the first 5 characters of an SHA-1 password hash to be passed to the API.
Notify Users About Unusual Security Events
When suspicious or unusual activity is detected, it may be appropriate to notify or warn the user. However, care should be taken that the user does not get overwhelmed with a large number of notifications that are not important to them, or they will just start to ignore or delete them.
For example, it would generally not be appropriate to notify a user that there had been an attempt to login into their account with an incorrect password. However, if there had been a login with the correct password, but which had then failed the subsequent MFA check, the user should be notified so that they can change their password.
Details related to current or recent logins should also be made visible to the user. For example, when they login to the application, the date, time, and location of their previous login attempt could be displayed to them. Additionally, if the application supports concurrent sessions, the user should be able to view a list of all active sessions and to terminate any other sessions that are not legitimate.