Brute-force attacks on login pages: what happens and what stops them
Every public login page is being tried by scripts right now. How the attacks work, why weak passwords fall fast, and five layers that stop them.
The short answer
Somewhere right now, an automated script is trying passwords against your website’s login page. It is not personal. Scripts scan the internet for anything with a login form, a content management system admin, a mail server, a remote desktop, and they try. Weak passwords fall in hours; reused passwords fall in seconds, because they were already leaked from somewhere else. The defence is not vigilance; it is five layers that make the attempt pointless, and the strongest of them is not having a public login at all.
Three kinds of attack
| Variant | How it works | What defeats it |
|---|---|---|
| Brute force | Many passwords against one account, from a dictionary or generated | Long random passwords, rate limits, lockout, two-factor |
| Password spraying | One common password against many accounts, slowly, to avoid lockout | No common passwords allowed, two-factor, monitoring of failures across accounts |
| Credential stuffing | Username and password pairs leaked from other breaches, replayed at scale | Unique passwords per service, two-factor, detection of leaked credentials |
The five layers
- Two-factor authentication. Even a correct password fails without the second factor. This one measure defeats all three variants. Use an authenticator app or a hardware key; codes by text message are better than nothing but weaker.
- Strong, unique passwords from a manager. Long, random, never reused. A manager makes this easy in practice; without one, people reuse.
- Rate limiting and lockout. A few failures, then a growing delay or a temporary block, per account and per source. Slow attackers down from thousands of attempts per minute to a handful per hour.
- A network layer in front. Known attacking sources and bot patterns are dropped before they reach the login page. Most of the noise disappears at the edge.
- No default login path, or no login at all. Move the admin off the path every script tries, restrict it by network where possible, and for websites, prefer an architecture with no public admin to attack.
Why static sites sidestep the problem
A static website has no login page on the public internet. Content is edited in a repository or a content system that lives elsewhere, behind its own two-factor, and the published site is files on a network. There is nothing to brute-force, and the thousands of daily attempts that fill a content management system’s logs simply do not exist. For a business website that does not need a public login, that is the cleanest answer to the problem.
What this means for you
Assume your login pages are being tried today, because they are. Turn on two-factor for every account that can log in to anything that matters. Use a password manager so every password is unique. Add rate limits and a network layer so the noise never reaches the server. Move admins off the default paths. And where a website does not need a public login at all, choose an architecture without one. Brute force only works against sites that make it possible.
Frequently asked questions
Our logs show thousands of failed logins a day. Are we under attack?
You are under the same background attack as every site with a public login page. It is automated and indiscriminate. The question is not whether it happens but whether it can succeed: with two-factor, rate limits and strong unique passwords, it cannot, and the noise can be filtered before it reaches the server.
Is a strong password enough on its own?
Against pure guessing, a long random password is effectively unbreakable. Against credential stuffing, where a password leaked from another service is replayed, strength does not help if it was reused. Unique per service plus two-factor is what closes both doors.
Should we hide or rename the login page?
It reduces noise from the crudest scripts, which is worth having, but it is not a security measure on its own; a determined attacker finds it. Do it after two-factor, rate limits and the network layer, not instead of them.
Sources
- OWASP Cheat Sheet Series: Authentication Cheat Sheet (accessed 2026-09-11)
- OWASP Cheat Sheet Series: Credential Stuffing Prevention Cheat Sheet (accessed 2026-09-11)