Account takeover and credential stuffing: shop defence

An account takeover rarely starts with a break-in to the database. It starts with ordinary login attempts: credentials that leaked from a breach at some other service are tried against your own login form (OWASP). Most fail, a few succeed, and the log shows nothing but slightly more traffic on a single URL. Before peak season this turns into an operational problem, because that traffic occupies the same queues as the checkout. This article walks through the defence chain stage by stage: rate limiting that does not only count by IP address, password rules that follow the current NIST guidelines, the second factor in the right place, and the response path once an account has been taken over. All of it rests on operations that keep count.

Credential stuffing is not password guessing

The two terms get mixed up in everyday conversation, yet they behave differently in operations. Password guessing tries many passwords against one account. Credential stuffing tries one username and password pair against many accounts – pairs that came from a breach at another service (OWASP). The OWASP project Automated Threats to Web Applications lists the technique as a separate automated threat under the identifier OAT-008: credentials stolen elsewhere are tried against an application's login in order to find reused credentials (OWASP). For defence, that difference decides everything. A cap on failed attempts per account works against guessing. Against credential stuffing it only helps in part, because per account there is often just a single attempt – what stands out is not the account, but the spread across many accounts.

Why the trying pays off at all shows up in an analysis of leaked datasets. The study evaluated 28.8 million people and their 61.5 million passwords across 107 online services (Virginia Tech). Among the people who appear with at least two cleartext passwords in those datasets, leaked between 2008 and 2016, 38% used exactly the same password at several services, and a further 20% modified an existing one (Virginia Tech). What is counted here are people, not accounts: the same person can appear in several leaks.

We find that 38% of the users have reused exactly the same password across different sites, while 20% have modified an existing password to create new ones.

Wang, Jan, Hu, Wang: Empirical Analysis of Password Reuse and Modification across Online Service (Virginia Tech)

The second finding of the same paper explains why capping failed attempts achieves anything at all. With a purpose-built guessing algorithm, more than 16 million password pairs could be cracked within ten attempts (Virginia Tech). Anyone who knows one password of a person often needs few tries for the second, because the modification follows patterns: a digit appended, a special character swapped, the service name worked in. A cap after a manageable number of failed attempts makes it harder to work through many modifications, but it does not catch everything: in the same study, all reused passwords and 30 percent of the modified ones fell within ten attempts. That said, the figures come from leaks of the years 2008 to 2016 and describe a guessing procedure run on leak data, not a measured attack on a live login.

The situation in Germany: what gets reported

For Germany, several surveys carry figures that matter directly for login waves. During the reporting period of the BSI situation report 2025, 461 data leaks containing data from institutions and from German consumers became known (BSI situation report 2025). Every such leak can supply material for trying credentials elsewhere, and it ages slowly: a password that has been in use unchanged for years remains usable even when the dataset itself is old. That is precisely why the number of leaks is relevant for a shop that had no breach of its own.

On the side of those affected, the Cybersicherheitsmonitor takes the measurements. Among respondents who had been affected by cybercrime in the last twelve months, 14% reported unauthorised access to an online account in 2026; the value before that was 8% (2025), 15% (2024) and 20% (2023) (Cybersicherheitsmonitor 2026). The series fluctuates, it does not rise steadily. A good one in four (27%) had been affected by cybercrime at some point, and for 40% of that group at least one incident fell within the past twelve months (Cybersicherheitsmonitor 2026).

On the company side, the Bitkom economic protection report counts, based on a representative survey of 1,003 companies in Germany with at least 10 employees and at least 1 million euros in annual revenue (Bitkom). Within that group, password attacks caused damage at 18% of companies in 2026, phishing at 16% and denial-of-service attacks at 15% (Bitkom). Ransomware sits above that at 25%, though down from 34% in the previous year and 31% in 2024 (Bitkom). Password attacks are therefore no marginal phenomenon – and of the listed causes of damage they are the one addressed directly at your own login form.

Police statistics provide the third perspective. For 2025 the police crime statistics report 333,922 cybercrime cases in total, an increase of 0.2% over the previous year (BKA). The burden thus stays at a high level, largely unchanged. Reported attacks using encryption trojans rose in the same year to 1,041 cases, 10% more than the year before (BKA). The statistics keep no separate category for account takeovers in retail. Anyone looking for that number for their own shop finds it only in their own log – and only if that log retains failed logins at all.

Why counting per IP address is not enough

The obvious defence is a cap per IP address, and against a single script it works. Against ready-made toolkits it often does not: many of them spread their requests across proxy networks onto a great many different IP addresses, so the request volume per address stays low. That can defeat both IP block lists and rate limiting per address, even for attacks with high overall volume (OWASP). If the same attack spreads across as many addresses as it makes attempts, one single attempt remains per address – and that one is indistinguishable from an ordinary login.

Where those addresses can come from is possible to place in terms of scale: during the reporting period the BSI reported around 40,000 infected systems per day to German network operators (BSI situation report 2025). What share such systems hold in the login traffic of a shop is quantified by none of the sources used here; the number describes the reservoir, not your own traffic. For defence that means: the origin of a request is a weak signal, behaviour across many accounts a strong one. Here is how a wave becomes visible in the log:

• The distribution is flat rather than peaked: many accounts, few attempts per account.
• The login error rate rises without any change in mailings, campaigns or time of day.
• Requests hit the login directly, without category or product pages loaded first.
• The share of unknown usernames rises: logins are tried against addresses without an account in the shop.
• Successful logins cluster on accounts that have been dormant for a long time.
• A successful login is followed not by an order but by a change of address or payment method.

If an address really does get blocked, the block needs its end date from the outset. OWASP recommends setting blocks on individual IP addresses for a limited time and keeping a process that lifts them once the abuse subsides or stops (OWASP). The reason is operational: behind one address there is often a whole network, a mobile carrier or the exit of a corporate network. An open-ended block then hits customers who did nothing, and it rarely gets noticed: those affected do not complain, they leave. How automated traffic is separated from customer traffic without a full block is covered in the article on bot traffic in the shop.

The defence chain in five stages

No single measure stops a login wave. What works is a chain in which every stage makes a different part of the attack more expensive: rate limiting costs time, a multi-step login costs requests, the block list check devalues the stolen passwords, the second factor devalues the password altogether, and the response path limits the damage on the accounts that fell anyway. The stages are deliberately independent of each other: if one drops out, the others keep working.

The third stage is regularly underrated because it looks technically trivial. A multi-step login – username and password one after the other, or a token that has to be fetched before the login – does not make the attack impossible, but it doubles the number of requests an attacker has to send per account (OWASP). For the other side, cost and duration double; for the customer, the flow barely changes. Such measures work in aggregate: each one shifts the economics of the attack a little, and beyond a certain point it moves on to the next target.

For rate limiting itself there is a solid upper bound. In SP 800-63B-4, NIST caps consecutive failed attempts per account and authenticator at 100 and requires that authenticator to be disabled afterwards (NIST). That is a ceiling, not a target value: in a shop a much lower threshold is common, combined with a growing delay instead of a hard lock. The advantage of the delay is that it slows the attack down without locking out an account that belongs to somebody who simply forgot their password.

<?php
// Count per account AND per network range: a wave spreads across many
// addresses but hits the same login form.
final class LoginGuard
{
    private const WINDOW = 900;        // observation window in seconds
    private const LIMIT_ACCOUNT = 10;  // failed attempts per account in the window
    private const LIMIT_NETWORK = 60;  // failed attempts per network range in the window

    public function __construct(private \Redis $store) {}

    public function mayAttempt(string $account, string $network): bool
    {
        return $this->count('account:' . $account) < self::LIMIT_ACCOUNT
            && $this->count('network:' . $network) < self::LIMIT_NETWORK;
    }

    public function failedAttempt(string $account, string $network): void
    {
        foreach (['account:' . $account, 'network:' . $network] as $key) {
            $value = $this->store->incr('login:' . $key);
            if ($value === 1) {
                $this->store->expire('login:' . $key, self::WINDOW);
            }
        }
    }

    public function success(string $account): void
    {
        // Only the account counter drops. The network counter stays, otherwise
        // every hit erases the trail of failed attempts next to it.
        $this->store->del('login:account:' . $account);
    }

    private function count(string $key): int
    {
        return (int) $this->store->get('login:' . $key);
    }
}

Two things matter here more than the concrete values. First, the counter runs separately per account and per network range, because a wave produces barely anything noticeable per account, but plenty per network range. Second, a successful login resets only the account counter. If it also cleared the network counter, a single hit could wipe out the trail of failed attempts beside it – and that pattern, one hit among many failures, is the signature of the technique. The store behind it should sit outside the application process, so the counters are the same across all web nodes in distributed operations.

Password rules under the current NIST guidelines

Many shops still work with rules that stem from the recommendations of the past decade. The current edition of the Digital Identity Guidelines reverses several of them. Where the password serves as the only factor, NIST requires at least 15 characters (NIST); as a maximum length, at least 64 characters should be permitted (NIST). Taken together that means: length is allowed rather than trimmed. An upper limit of 20 characters, as found in older shop systems, rules out precisely the passphrases customers can remember without reusing them.

• Check every new or changed password against a block list of known, commonly used or compromised passwords (NIST).
• Do not require periodic password changes – the NIST guidelines explicitly rule that out (NIST).
• Do not enforce composition rules such as mandated mixes of character types (NIST).
• Check new passwords against leak datasets; for this OWASP points to requirement 2.1.7 of the Application Security Verification Standard v4.0 (OWASP).
• Trigger a reset on suspicion instead of leaving it to the customer – and terminate all open sessions of the account.

The block list check is the stage that hits credential stuffing at the root: a password that is on the block list is rejected when it is created or changed. In implementation there are two routes. Either the list sits in your own operation – a collection of hashes queried when a password is set – or the check runs against a lookup service that only sees a prefix of the hash. The first route keeps the data in house and stays manageable with a limited list; the second shifts maintenance and scope outwards and brings a dependency that has to appear in the record of processing activities.

The second factor and what slows it down in a shop

The second login stage was used more often in 2026 than in the previous year. By their own account, 40% of respondents used two-factor login in 2026 after 34% the year before, and 21% passwordless login after 16% (Cybersicherheitsmonitor 2026). The term passkeys was known to 38% of respondents in the BSI consumer survey, while 18% had used it (BSI situation report 2025). At the same time, 8% of respondents use no protective measure against cyberattacks at all (Cybersicherheitsmonitor 2026). A shop can therefore rely neither on its customers knowing the second factor nor on them rejecting it.

In practice the second factor rarely fails on technology and often on placement. Hang it on every login and you lose orders; bury it in the account area and you miss the customers who need it. Staging by risk is workable in our experience: an ordinary login without an extra hurdle, a second factor when logging in from an unknown device, when changing payment data, delivery address or stored details, and when resetting the password. How passwordless login works technically is covered in the article on passkeys in e-commerce; how registration avoids dragging on in the article on designing customer accounts.

When an account has been taken over

The response path is a part of the chain that is often missing, although roughly one in three of those affected turns to the operator of the service. Among those affected in the last twelve months, 35% turned to the operator of the service in 2026 and 32% filed a police report (Cybersicherheitsmonitor 2026). The operator and the police are therefore contacted about equally often. For a shop that means: the path has to be staffed by a person allowed to act, not just by a mailbox. A customer who reports unauthorised access and waits three days for a canned reply is usually lost twice over. How a feedback path that is staffed and meets a deadline is built is shown in the article on the accessibility statement with a feedback mechanism.

1. Terminate all open sessions of the affected account, not just the current one.
2. Reset the password and set up the second factor anew instead of keeping the old one.
3. Check stored data: delivery addresses, payment methods, phone number, email address – exactly the fields an attacker changes first.
4. Review the orders of the last few days and stop open shipments still in the warehouse.
5. Write to the customer about what happened and what to do – above all if the same password is in use elsewhere.
6. Record the incident in the log: time, origin, accounts affected. Without that note a single case cannot later be told apart from a wave.

The evaluation shows the pattern more clearly than any assumption: many addresses, hardly any repetitions, overwhelmingly one failed attempt per username. The username is not in the web server access log because it is sent in the request body; the last query therefore uses the shop's own login log, which records time, IP address and a hash of the username per failed attempt, in that order. Rate limiting per IP address would have had almost nothing to block here. For such evaluations, failed logins have to be logged – with purpose limitation, a retention period and a decision on whether the address is stored truncated. What to observe belongs in the record of processing activities and in data protection; who may look at those logs is governed by permissions in the shop back end.

Who carries which obligation

Legally the picture is clearer than often presented, above all as regards who is addressed. Essential and important entities have to deploy solutions for multi-factor authentication or continuous authentication under Section 30(2) number 10 BSIG (BSIG). The German BSI Act as amended by the NIS2 implementation entered into force on 6 December 2025 (BSIG). The obligation therefore does not hit every shop operator, but the entities defined in the act. Who belongs to them is covered in the article on the NIS2 directive for online retailers.

For the same entities a staged reporting chain applies. A significant security incident has to be reported without undue delay, at the latest within 24 hours of becoming aware of it, as an early warning to the joint reporting office, stating whether there is a suspicion of unlawful or malicious acts or of cross-border effects (BSIG). In practice that means the decision on whether an incident is significant has to be prepared before the incident. A classification first discussed in an emergency consumes exactly the hours the deadline allows.

On top of that comes a regulation whose timetable is often quoted in abbreviated form. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements applies from 11 December 2027; Article 14 with the reporting obligations of manufacturers, however, has applied since 11 September 2026, and Chapter IV since 11 June 2026 (Regulation (EU) 2024/2847). The reporting obligations are therefore applicable law and not an announcement. They address manufacturers of products with digital elements – relevant for shop operators where own software or connected products are distributed. The scope is described in the article on the Cyber Resilience Act.

Where attackers get in, by the numbers

For the question of how much attention the login form deserves, the intrusion vectors are worth a look. For the Threat Landscape 2025, ENISA collected and curated a total of 4,875 incidents (ENISA). Within the cases where the intrusion vector could be determined, about 60% fell to phishing including vishing, malspam and malvertising, 21.3% to the exploitation of vulnerabilities, 9.9% to botnets, 8% to malicious applications and 0.8% to unauthorised access by insiders (ENISA). The shares add up to the whole within this subset: they describe the distribution among cases with a determined intrusion vector, not the share of all evaluated incidents, which overall are dominated by denial-of-service attacks.

The second figure of this chapter explains the supply for the trying: of the recorded intrusions, 68.6% led to data breaches subsequently offered for sale on underground forums (ENISA). This value too refers to the intrusions, not to every security incident. Taken together a cycle emerges: a break-in elsewhere produces credentials that get traded, and those credentials hit login forms weeks later that have nothing to do with the original incident. In this cycle your own shop is the test bench, not the source.

Catching login waves before peak season

The order of the work follows from the effort: counting first, then limiting, then the password rules, then the second factor. We start with the log and check whether failed logins are stored in an evaluable form. Then we set up the counters per account and per network range, bring the password rules to the current state of the NIST guidelines, and define where a second factor is required. For the load side of the same preparation – capacity, emergency plan, fallback route – there is the article on load testing and the emergency plan.

• Take stock of the login path: which routes lead to a login, and which of them are rate limited?
• Set up counters per account, per username and per network range, shared across all web nodes.
• Align the password rules: minimum length, permitted maximum length, block list check, no periodic change.
• Hook in the second factor on a risk basis, starting with changes to payment and address data.
• Define the response path: who reports, who decides, who writes to the customer – with a deputy.
• Measure again after four weeks: failed attempts per account, share of unknown usernames, successful logins after long account dormancy.

We set up this chain during live operation and change the login for your customers only where a stage requires it: counters and logging come first, and the thresholds are set from the measured distribution rather than from a reference value taken from somebody else's shop. If you want to know how your login path stands in its current state, the shop check is the short route; for operations, logging and counters across several nodes, the route runs via hosting and maintenance. In both cases the rule holds: measure first, then limit – a threshold derived from an assumption usually locks out the wrong people.