What is a brute-force attack and how do websites stop it?

Look at the access logs of almost any public website with a login page and you will see it: request after request to the sign-in URL from addresses you do not recognise, often at three in the morning. That is a brute-force attack in progress, usually automated, usually aimed at thousands of sites at once, and usually hoping for a weak or reused password.

Most of these attempts fail. The ones that succeed tend to find a site with no defences at all. This guide explains the main forms of password attack in plain terms and the layers of protection that stop them.

The basic idea behind brute force

At its simplest, brute force means trying possibilities until one works. For a login, the attacker picks a username and submits password after password. The concept is old and unsophisticated, but automation makes it cheap: a script can send many attempts per second and run indefinitely from rented servers or infected devices.

In practice, attackers rarely try every possible combination. They use shortcuts, and those shortcuts define the three variants below.

Three kinds of password attack

1. Pure guessing

The attacker systematically tries combinations: aaaa, aaab, aaac and so on. Against a long password this is hopeless over a network, which is why it is mostly used against short PINs, OTP codes without attempt limits, or offline against stolen password hashes.

What it exploits: short secrets and endpoints that allow unlimited tries.

2. Dictionary attacks

Instead of every combination, the attacker uses a list of likely passwords: common choices, words, names, keyboard patterns and predictable variations like adding a year or an exclamation mark. Usernames such as admin, administrator, info or the business name are paired with each.

What it exploits: human habits and default or guessable usernames.

3. Credential stuffing

This is now the most damaging variant for many businesses. Attackers take real email and password pairs leaked from breaches of other websites and try them on yours. Because many people reuse passwords, a meaningful share of those pairs work somewhere.

Credential stuffing looks different from classic brute force. Each account may see only one or two attempts, spread across many IP addresses, so simple “five failures and lock” rules may never trigger.

What it exploits: password reuse across sites.

A related variant: password spraying

Here the attacker tries one or two very common passwords against many different accounts, staying under per-account lockout thresholds. It is often aimed at organisations with staff accounts on a single system.

Why a successful guess hurts a small business

The damage depends on which account falls:

• Admin or editor account: defaced pages, injected spam links, malicious scripts that redirect visitors, or new hidden admin users.
• Customer accounts: exposed addresses and order history, misuse of stored wallet balances or loyalty points, fraudulent orders.
• Hosting or email accounts: complete takeover of the website and ability to reset other passwords.

Even unsuccessful attacks cost something: bursts of login requests consume server resources and can slow the site for real visitors on modest shared hosting.

Layered defences that match each attack

No single control stops everything. Layer several, and each covers the gaps of the others.

Layer 1: Strong, unique passwords and breach screening

Require reasonable length, block passwords known from breaches and common lists, and encourage password managers. This blunts dictionary attacks and reduces the value of stuffed credentials.

Layer 2: Throttling and progressive delays

Limit how quickly attempts can be made against an account and from a network source. This makes pure guessing and dictionary lists impractically slow. It needs careful tuning so real users are not locked out, which is a topic of its own.

Layer 3: Bot detection and challenges

Credential stuffing spreads across many IPs, so look at wider signals: unusual login volume sitewide, many failures for accounts that do not exist, identical browser fingerprints. Services such as Cloudflare’s bot management features or a CAPTCHA shown only when traffic looks suspicious can filter automated traffic without bothering most people.

Layer 4: Two-factor authentication

This is the layer that makes a correct password insufficient. For admin and staff accounts, it is the single most effective protection against every attack in this article.

Layer 5: Reduce the attack surface

• Avoid predictable admin usernames and do not display usernames publicly where you can help it.
• Disable login interfaces you do not use, such as XML-RPC on WordPress if no app relies on it.
• Restrict admin areas by IP address or VPN where your team works from known locations.
• Put the site behind a web application firewall that can block known abusive sources.

Layer 6: Monitoring and response

Log failed and successful logins with time, account and IP. Alert on spikes. When stuffing is detected, notify affected users and require a password reset for accounts that logged in successfully from suspicious sources.

A quick self-check for your website

Answer yes or no to each question:

1. Does every admin account use two-factor authentication?
2. Is there a limit on repeated login attempts, including API and app endpoints?
3. Are breached and common passwords rejected at sign-up and password change?
4. Is there an account called “admin” with administrator rights?
5. Would anyone notice a sudden surge of failed logins tonight?

Every “no” on questions 1, 2, 3 and 5, and a “yes” on question 4, is a gap worth closing this month.

Getting protection in place

Start with two-factor authentication for admins and attempt limits on the login page, because together they stop the majority of automated attacks. Then add monitoring so you can see what is happening. Hosting matters too: our VPS hosting lets you configure server-level protection, and our team can advise through support if you suspect attacks on your current site.

Frequently asked questions

How can I tell if my website is under a brute-force attack?

Signs include many failed login entries in server or security plugin logs, repeated requests to the login URL from unfamiliar IPs, lockout notification emails and unexplained slowdowns on the login page.

Is credential stuffing the same as brute force?

They are related. Brute force guesses passwords, while credential stuffing reuses real username and password pairs leaked from other sites, so it needs far fewer attempts per account.

Does changing the login URL stop brute-force attacks?

It reduces noise from basic bots but is not real protection, since the new address can be discovered. Treat it as a minor extra alongside attempt limits and two-factor authentication.

Can a brute-force attack slow down my website?

Yes. Each login attempt requires processing and password hash checks, so a heavy attack can consume noticeable resources, particularly on shared hosting.