Stopping a credential-stuffing attack that pushed worst-case page time on four websites to about 70 seconds.
A law firm came to us in the middle of a credential-stuffing attack on its four websites. We stopped more than 95% of the attack traffic before it reached the host, and worst-case page time fell from about 70 seconds to 1 to 3 seconds.
Before and after.
How the work went.
What was happening
Credential stuffing takes username and password pairs leaked from other sites and tries them in bulk. Each attempt looks like a normal login, so the server does real work for every one. At that volume, real visitors waited in the same queue as the attack.
What we did
We put filtering in front of the host, which stopped more than 95% of the attack’s login requests before they reached it. Worst-case page generation across the four sites fell from about 70 seconds to 1 to 3 seconds.
What we left in place
Afterwards we added access controls, monitoring and alerting, and a written runbook. If it happens again, the team has a procedure to follow.
Keep reading.
Questions about this case study.
Not covered here? Send us your question and an engineer will answer it.
Ask a question- What is the difference between credential stuffing and a brute-force attack?
- A brute-force attack guesses many passwords for one account. Credential stuffing tries username and password pairs leaked from other sites, usually once each across many accounts, so each request looks like a normal login.
- Why does a login attack slow down the whole website?
- Every login attempt costs the server real work. When thousands arrive at once, real visitors wait in the same queue. Stopping the attack traffic before it reaches the host gives that capacity back.