What is credential stuffing? A leaked password tried elsewhere

What the sources mean by credential stuffing

OWASP’s page on the attack defines it as the automated injection of stolen username and password pairs, which it calls “credentials”, into website login forms, in order to gain access to user accounts fraudulently. It gives the reason in the next paragraph: many users re-use the same password and username or email, so when a pair is exposed, by a database breach or a phishing attack for example, submitting those stolen pairs into dozens or hundreds of other websites can let an attacker compromise those accounts too.

The NSA, in an article dated 20 December 2018, tells the same story from the side of the person with the account. A hacker acquires a large quantity of usernames and passwords, potentially from a previous attack or from a website that publishes stolen data, “often found on the Dark Web”. The hacker then runs them through tools that test them across multiple websites. The NSA’s example is a username and password compromised at a Company A that suffered a breach: if the same pair opens a social media account, that account could be in jeopardy too. It adds that the personal information in such accounts, potentially including credit card numbers, bank accounts and social security numbers, is then vulnerable as well.

Cloudflare, whose page sits in the learning section of a company that sells bot management, uses a different example. An attacker takes a list of usernames and passwords from a breach of a major department store and tries the same logins on the site of a national bank, hoping that some of those customers also have an account there and reused the pair. OWASP says credential stuffing is “one of the most common” techniques used to take over user accounts, and that it is dangerous to consumers and to enterprises alike because of the ripple effects from one breach to another. The pages we read do not say how many accounts are taken over each year.

How the attack runs, step by step

OWASP breaks the attack into steps. First the attacker acquires usernames and passwords from a website breach, a phishing attack or a password dump site. Then automated tools test the stolen credentials against many websites, for instance social media sites, online marketplaces or web apps. If a login succeeds, the attacker knows the pair is valid. After that, OWASP lists what may follow: draining the account of stored value or making purchases, reaching sensitive information such as credit card numbers, private messages, pictures or documents, using the account to send phishing messages or spam, and selling the known-valid credentials to other attackers.

OWASP’s diagram makes it concrete. The database of a site called acme.com is compromised, and the attacker tries its pairs on three other websites. On two of them the user named “spongebob” is reusing the password, and on one the user named “sally” is, so the attacker reaches three accounts. In OWASP’s example every pair came from the first breach rather than from guessing.

Both Cloudflare and OWASP’s prevention guide explain why the usual brakes do not stop it. Cloudflare says login forms often include deliberate time delays and bans on IP addresses with repeated failed logins, and that credential stuffing software gets around them with bots that attempt several logins at once from a variety of device types and different IP addresses, so that the attempts look like ordinary login traffic. It adds that the only sign the company under attack has may be a rise in the overall volume of login attempts. The OWASP guide says many toolkits, “such as Sentry MBA”, offer built-in use of proxy networks to spread requests across a large number of unique IP addresses, which may defeat both IP block-lists and rate limiting, because the volume from any one address can stay low even in a high-volume attack.

OWASP also notes a route that needs no reused password. Information found in data leaks can be used to reset passwords, particularly for business accounts, because business information is often public and phone numbers and email addresses are easier to obtain or guess. The method uses security questions, recovery emails or other personal information that might be in the breach, so an account can be taken over even if the password was not reused.

Why it works when most tries fail

Cloudflare is the one page we read that puts numbers on it, and the numbers are its own estimates. It says credential stuffing has a very low rate of success, and that many estimates put the rate at about 0.1 percent, roughly one success for every thousand accounts tried. Because the collections being traded hold millions of login credentials and in some cases billions, one million pairs could yield around 1,000 accounts, and the attacker can repeat the process on other services. The page does not name a study behind the 0.1 percent.

On reuse, Cloudflare says studies suggest that a majority of users reuse their login credentials for multiple services, “by some estimates as high as 85%”. That page does not name the studies either, and the OWASP, NSA and CISA pages we read give no general figure for how many people reuse a password; the only number on OWASP’s page is the Sony passage quoted below, which concerns users found in two particular data sets. The NSA only says that a lot of people do it for ease of access, and that there is no reason to be embarrassed if you have.

A strong password does not change this. Cloudflare says a strong password of several characters, including uppercase letters, numbers and special characters, is a good defense against brute force attacks, but that password strength does not protect against credential stuffing: it does not matter how strong a password is if it is shared across different accounts. CISA’s page, which is marked as archived and was revised on 18 November 2019, says the same about reuse: reusing a password, even a strong one, endangers your accounts just as much as using a weak one, because if attackers guess it they have access to the other accounts that use it.

One more point from Cloudflare changes who is to blame. A company hit by credential stuffing has not necessarily had its own security compromised, because the attack comes from data breaches at other companies. The company can suggest that users choose unique passwords, Cloudflare says, but cannot effectively enforce it.

Credential stuffing, brute force and password spraying

The sources do not describe the relationship the same way. OWASP’s page on the attack calls credential stuffing a subset of the brute force attack category. In that page, brute forcing attempts multiple passwords against one or several accounts, which is to say guessing a password, while credential stuffing typically refers to using known, breached username and password pairs against other websites.

Cloudflare reports that OWASP classifies it that way and then disagrees: “strictly speaking”, it writes, credential stuffing is very different from traditional brute force. Brute force, in its words, attempts to guess passwords with no context or clues, using characters at random and sometimes common password suggestions, while credential stuffing uses exposed data, which dramatically reduces the number of possible correct answers. We report both wordings and do not pick one.

OWASP’s prevention guide adds a third attack and sets the three side by side in a short table, shown below. It describes credential stuffing and password spraying as separate, distinct attacks, notes that many of the defenses against them are the same, and says those defenses would also work against brute force. In that table, brute force is testing multiple passwords from a dictionary or other source against a single account, credential stuffing is testing username and password pairs obtained from the breach of another site, and password spraying is testing a single weak password against a large number of different accounts. The attack page words brute force more loosely, as multiple passwords against one or several accounts.

Cases on record

OWASP’s page ends with excerpts from publications analyzing large-scale breaches, and says the evidence supports that these breaches were the result of credential stuffing. The page quotes four, and we repeat only what it quotes.

For the Sony breach of 2011, the quoted passage, which OWASP credits to AgileBits and Wired, says that two-thirds of the users whose data were in both the Sony data set and the earlier Gawker breach had used the same password for each system. For the Yahoo breach of 2012, OWASP quotes Troy Hunt asking what Sony and Yahoo have in common, and answering with one word: passwords. For the Dropbox breach of 2012, it quotes Dropbox saying that the usernames and passwords in the articles were stolen from unrelated services, not Dropbox, and that attackers then used them to try to log in to sites across the internet, Dropbox among them.

The fourth case is set apart. For the JPMC breach of 2014, OWASP quotes the New York Times: the breached data contained some of the combinations of passwords and email addresses used by participants who had registered on the Corporate Challenge website, an online platform for annual charitable races that JPMorgan sponsors and that is run by an outside vendor. OWASP states that the chain from Sony to Yahoo to Dropbox excludes JPMC, whose breach came from a separate and unrelated source, a third-party race site that attackers targeted for credentials to use against JPMC.

What each source says to do

For the person with the account. The NSA gives the only order of actions in the pages we read. Pay attention when major breaches occur; if you have an account with a company that suffers one, do not waste time in changing your password; if you use that same pair for other accounts, change those passwords as well. It then suggests making this the moment to create a unique username and password combination for every account, using two-factor authentication when possible for additional protection, and, if you have a lot of accounts, considering a password manager. The NSA does not say which of the other accounts to change first, and the pages we read do not either, so any ranking of email, bank and social accounts would be our own choice.

Cloudflare’s version is shorter. Use a unique password for each service, and it says a password manager is an easy way to achieve that: if a user always uses unique passwords, credential stuffing will not work against their accounts. It encourages two-factor authentication as an added measure when it is available. CISA’s archived page says to use different passwords on different systems and accounts, the longest password the system permits, and to consider a password manager. These pages present a manager as a way to keep unique passwords, not as a guarantee. For the steps themselves, see our pages on whether Bitwarden is safe, on two-factor and two-step sign-in and on authenticator apps.

For the service that runs the login. OWASP’s attack page names multi-factor authentication a primary counter-measure. Its prevention guide goes further and calls multi-factor authentication by far the best defense against the majority of password attacks, citing an analysis by Microsoft that suggests it would have stopped 99.9 percent of account compromises; we did not check that figure at a Microsoft page. The guide mentions FIDO2 passkeys, and says a second factor can be asked for only when a login looks suspicious: a new browser, device or IP address, an unusual country, an address on a denylist or tied to proxy or VPN services, an address that has tried several accounts, or an attempt that looks scripted.

On breached passwords, the sources vary. Cloudflare says some applications check a submitted password against a database of known compromised ones, but that this is not foolproof, because the user could be reusing a password from a service that has not yet been breached. The OWASP guide points to a requirement in version 4.0 of its application security standard, numbered 2.1.7, on checking new passwords against breached datasets, and to Pwned Passwords, a free service that can be hosted by the service itself. The NIST text we read, SP 800-63B revision 3, says verifiers shall compare a chosen password against a list of values known to be commonly used, expected or compromised, which can include passwords from previous breaches, and shall require a different one if it is found. That page states that NIST has since replaced revision 3 with SP 800-63-4; we did not read the newer text.

The guide lists other layers and is candid about their limits. A CAPTCHA may slow an attack, but CAPTCHAs are not perfect, since tools exist to break them. Blocking IP addresses should not be the sole or primary defense. Device fingerprinting runs on the client and can be spoofed. It suggests requiring users to pick a username that is not an email address, because many of the credential lists contain only email addresses, adding steps to the login, requiring JavaScript (with a warning about accessibility), and slowing attackers on purpose. It also suggests telling users about unusual security events, while allowing that the user’s email account may itself be compromised. Cloudflare calls a bot management service “the strongest protection”; that is a company describing its own kind of product.