Guide SSL & Security

How to stop brute-force login attacks

Automated tools quietly try thousands of guesses against your login form. A few layered defences make that approach stop being worthwhile.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

A brute-force attack against a login form is not usually a person sitting there guessing passwords. It is an automated tool trying large numbers of common passwords, or credentials leaked from unrelated breaches, against your login page as quickly as it is allowed to. It succeeds often enough to be worth running at scale precisely because a meaningful number of accounts everywhere use weak or reused passwords — the defence is making sure yours is not one of them, and making the attempt itself expensive to keep running.

Limit the number of attempts allowed

The single most effective, specific defence is limiting how many failed login attempts are allowed from the same source in a given period, then temporarily blocking further attempts once that limit is reached. This does not affect a genuine user who occasionally mistypes a password, but it makes an automated tool trying thousands of guesses take drastically longer, to the point where it is no longer a practical approach against your site specifically.

Many CMS platforms support this through a plugin or built-in setting, and it is worth checking whether yours is enabled — it is one of the most effective changes available for a small amount of setup effort, and it needs no ongoing attention once configured.

Use strong, unique passwords

A brute-force attack succeeds fastest against common or previously leaked passwords, since automated tools work through known lists before resorting to a slower, truly random search. A long, unique password that has never appeared in a data breach makes the guessing approach dramatically less likely to succeed within any practical timeframe. How to choose passwords worth having covers what actually makes one strong.

Add two-factor authentication

Even a leaked or eventually guessed password stops being enough on its own once a second, independent check is required. This is the layer that protects you even if the previous two somehow fail — a genuinely unlikely combination, but two-factor authentication removes the risk of relying on password strength alone. How to turn on two-factor authentication covers setting this up.

These layers are meant to work together

No single one of these is a complete defence by itself. An attempt limit slows the attack down, a strong password makes it unlikely to succeed within that window, and two-factor authentication catches the case where a password is compromised through some other means entirely, such as a breach at an unrelated service.

Avoid an obvious, guessable username

Some platforms allow the login username to be the same as a publicly visible display name, or default to a predictable value like "admin". Where you have the choice, use something that is not publicly guessable as the login username specifically, separate from any name you display publicly on the site — this does not stop a determined, well-informed attacker, but it does remove the easiest and most common target from an automated tool working through a generic list of default usernames.

Block a specific persistent source directly

If your logs show one address responsible for a sustained, specific attempt against your login page, blocking that address directly is a reasonable additional step. How to block an IP address from your site covers doing this through your control panel or directly in .htaccess. Treat it as a targeted response to a specific, identified source rather than a general-purpose defence, since an attacker using many different addresses at once will simply route around a block on any single one.

A brute-force attempt against the login form itself is only one route in. An outdated CMS, plugin or theme with a known vulnerability can sometimes be used to bypass the login entirely rather than guess through it, which makes keeping software up to date a security measure in its own right, not just good housekeeping.

Why this is worth doing even on a small site

Automated login attempts are not targeted at your site specifically in the way the word "attack" might suggest — the same tools work through enormous, indiscriminate lists of addresses regardless of how small or unremarkable the site behind each one is. A brand new site with almost no visitors can still see login attempts within days of going live, simply because it now has a public login form for a tool to find. Being small is not a reason to skip these layers.

What to check if you suspect an attack is under way

Look at your access logs for a spike in failed login attempts, particularly against a common username, arriving in a short window or from a small number of addresses. If you find this pattern, apply the layers above rather than any single one, and if the site shows any sign the attack actually succeeded — an unfamiliar admin account, changed content, unexpected files — move to what to do first if your website is hacked rather than continuing to treat it only as an ongoing attempt.

Frequently asked questions

How do I know if my site is under a brute-force attack?

A large number of failed login attempts in your access logs, often against a common username like "admin", arriving in a short space of time or from a small number of addresses, is the typical pattern. Genuine users very rarely produce that volume of failed attempts on their own account.

Is renaming my admin username enough on its own?

It removes the easiest target but is not a complete defence by itself, since an attacker can still discover a valid username through other means in some setups. Treat it as one layer alongside a strong password, two-factor authentication and an attempt limit, not a replacement for any of them.