Building a layered defense against account takeover attacks
Seven controls that stop account takeover before the login succeeds: WAF, bot management, rate limits, login monitoring, MFA and password managers.
Billions of dollars are lost every year to criminals who break into other people's financial accounts. An account takeover starts the moment someone else's credentials work on your login form. From there the attacker drains stored balance, changes the payout details or buys with the saved card. No single control stops it. Seven layers, each covering a gap in the last one, do.
Do not depend on one product. Start with the scenario that would cost you most, for example a credential stuffing run against accounts with saved cards, put a control in front of it, then add the next layer.
The layers below are a web application firewall, bot management, rate limiting, login monitoring, defense in depth, MFA and password managers. Together they catch an attack before it becomes a chargeback or a support ticket.
How to build a layered defense against account takeover
Each control below closes a gap the previous one leaves open. Put them in place in roughly this order.
1. Web application firewall (WAF)
A web application firewall sits between the client and your server, inspects each request and drops the ones that match an attack pattern.
It stops SQL injection and cross-site scripting, absorbs part of a DDoS flood and filters known botnet traffic. A 2022 forecast put the WAF market at $5.48 billion, which says how standard the control has become.
You can also use it to block requests for specific paths or file types, and to block whole countries by IP address when a region sends you attacks and no customers.
2. Bot management solution
Credential stuffing is run by bots, so a bot manager removes most takeover attempts before they reach your login endpoint. It tells malicious bots apart from browsers and good crawlers by how they connect and behave, then blocks or challenges them.
It also throttles scrapers and other noisy crawlers that inflate your traffic numbers and your server load.
3. Rate limiting
Rate limiting caps how many requests one client can send to your login or API in a given window. Use a fixed window, or a sliding one that resets as time passes.
The usual rule is to allow the first N requests in a period and reject the rest, where N is the number of requests per second your limit permits.
For login endpoints set N low enough that guessing passwords under the limit would take longer than any attacker will spend, and high enough that a real user who mistypes twice never sees it. Key the limit on the account and the IP range as well as the single IP, because stuffing tools rotate addresses.
4. Monitoring
Monitoring is the layer that tells you a takeover happened, when, and what the attacker did with the account. Without it, the first sign is a chargeback or an angry customer.
Watch for:
- Login anomalies: a new device, a new country, impossible travel, or bursts of failed attempts spread across many accounts.
- Changes to sensitive data straight after login, such as the password, the email address or the payout details.
- Unauthorized reads of sensitive data, for example an account pulling records it never touched before.
5. Layer the controls (defense in depth)
Defense in depth means no single control is trusted to hold on its own.
If an attacker gets past one layer, the next one is waiting. A stuffing tool that evades the bot manager still hits the rate limit. A request that stays under the rate limit still has to pass a risk check at login. A correct password still runs into MFA.
The risk check is the layer that catches a valid password used from the wrong place. Score each login from device, network and behaviour signals, and let the score decide whether the attempt goes straight through, gets a step-up challenge or is blocked.
6. Add multi-factor authentication
Turn on MFA for every account that holds money or data. One widely cited figure is that it blocks 99.9% of breach attempts.
Multi-factor authentication checks two or more things: something the user knows (a password or PIN), something they have (a phone or hardware token) and something they are (a fingerprint or face). Attackers have ways around the weaker factors, so prefer app or hardware factors over SMS codes.
A stolen password then gets the attacker nothing without the second factor.
7. Use a password manager
Strong passwords still matter. People cannot remember a unique one for every site, so they reuse them, and reuse is what credential stuffing runs on.
A password manager generates a long random password for each service and stores them all in an encrypted vault.
When the user logs in, the manager fills the credentials for the matching domain. That also defeats look-alike phishing domains, because the manager will not fill them.
Make a manager mandatory for your own staff. For customers, stop blocking pasted passwords on your login form so their managers work.
Where to start
Account takeover is an attack on your login, not on your fraud model, so start at the login.
Put a WAF and bot management in front of the form this week, add rate limits on the login and password reset endpoints, and turn on MFA for staff and high-value customers. Then add monitoring so you see the attempts that get through.
To score every login from device, network and behaviour signals and let your rules allow, review or block it, see account takeover protection.