Every service reachable from the internet - a mailbox, a website’s admin panel, remote access to a server - sooner or later gets attempts to guess its credentials. Usually there’s nothing personal about it: most of that traffic is automated and indiscriminate. Understanding what a brute force attack is, why it’s so common, and which basic defenses address it helps protect any exposed system without relying on magic solutions.

What a brute force attack is

A brute force attack is an attempt to guess a credential - a password, a code, a key - by trying many combinations one after another until one works. There’s no cleverness to it: there’s volume. The documentation from OWASP, the non-profit that focuses on web application security, describes it as configuring predetermined values, sending them to a server, and analyzing the response to see whether they worked. The name says it all: you’re guessing, but many times and fast.

The engine behind these attacks is automation. A human trying passwords by hand is painfully slow; a program tries thousands per second. Hence the classic distinction between two approaches. In “pure” brute force, combinations are generated one by one (every sequence of letters, numbers, and symbols): exhaustive but slow, and the longer the password, the slower it gets. A dictionary attack, by contrast, starts from lists of common words and passwords, often collected from old data breaches: less exhaustive, but far faster at catching anyone using weak or already-known credentials.

Why every exposed service gets them

The most natural question is: why my server? In most cases the answer is that it isn’t “yours.” Networks of compromised computers - so-called botnets - sweep entire ranges of IP addresses looking for open ports and login pages. Once they find a target, they try default credentials, common passwords, and username/password pairs leaked from other services. It’s background traffic, like noise in a city: anyone with an SSH port, a mail server, or a login form receives it, often thousands of attempts a day.

This changes how you should think about it. You don’t need to be an “interesting” target: being reachable is enough. And because these attacks are automated and cheap, they don’t stop on their own. The goal of defense isn’t to become invisible, but to make each attempt costly and unrewarding enough that it leads nowhere.

Not one attack, but a family

The “brute force” label covers a few variants worth telling apart, because they call for slightly different defenses.

• Dictionary attack. As mentioned, it uses lists of frequent words and passwords instead of trying every combination. It’s effective against predictable passwords like password123 or the company name.
• Credential stuffing. OWASP classifies this as a subset of brute force. Here the attacker doesn’t guess: they reuse username/password pairs stolen in one breach to try them on other services. It works for a simple, widespread reason: many people reuse the same password everywhere. If it leaked from one site, it gets tried on all the others.
• Password spraying. The attacker tries a few very common passwords against a large number of accounts, rather than hammering a single one. This avoids the lockouts that trigger after too many failed attempts on the same user.

The basic defenses

No single measure is enough. Effective protection is built from several layers that add up, so that when one fails the door isn’t left wide open.

Strong passwords and keys

The first barrier is making the credential hard to guess. A long password dramatically increases the number of possible combinations, and therefore the time needed to try them all. OWASP’s guidance recommends a minimum length of 15 characters when no second factor is in place, and suggests allowing passwords up to at least 64 characters so as not to penalize passphrases - phrases that are easy to remember and hard to guess. Just as important is not reusing the same password across services: a password manager makes it easy to keep a different, random one for each, though where the service allows it the most effective move is replacing it altogether with a passkey.

On servers there’s an even better option than passwords: cryptographic keys. An SSH key is vastly longer and more random than any memorable password, to the point of making brute force practically useless. Replacing password login with key-based login removes much of the problem at the root, a measure that can be reinforced further by tucking access behind a VPN like WireGuard.

Multi-factor authentication (MFA)

Multi-factor authentication (MFA) requires, on top of the password, a second independent element: a temporary code from an app, a physical security key, a fingerprint. The idea is that guessing or stealing the password alone is no longer enough. According to OWASP, MFA is by far the best defense against most password-related attacks, brute force included; the same source cites a Microsoft estimate that it would have stopped 99.9% of account compromises. It’s the single measure that moves the needle most: even if an attacker gets the password right, without the second factor they don’t get in.

Slowing down and limiting attempts

If an attack lives on volume and speed, a natural defense is to take both away. Rate limiting caps the number of attempts accepted within a given time window. Small pauses after each error, a temporary block after a set number of failures (account lockout), or a CAPTCHA - those tests that are easy for a human and annoying for a program - make an attack slow and impractical.

Honesty is needed here, though: OWASP warns that plain account lockout can backfire. An attacker can flood a legitimate user’s account with wrong attempts on purpose just to lock them out, turning the defense into a small denial-of-service attack. That’s why more targeted approaches are often preferred - tied to the device or the source address - which hit the origin of the abuse instead of the user.

Blocking the IPs that keep trying

The last layer is reacting to whoever keeps trying. There are tools that watch the system’s logs, which should be kept only as long as the GDPR’s data minimisation principles allow, and automatically block addresses that are too persistent. The best-known example in the Linux world is fail2ban, free software that, as its official description puts it, scans log files (for example /var/log/auth.log) and bans the IP addresses responsible for too many failed login attempts by updating the system firewall rules to reject new connections from them for a configurable amount of time.

In practice: if an address gets the credentials wrong too many times in a short window, the door is shut on it for minutes or hours. It doesn’t prevent the first attempt, but it silences the background noise and raises the cost of persistence. It’s a good example of a reactive defense, complementary to - not a replacement for - the ones above.

The limits to keep in mind

Blocking IPs isn’t a final solution, and it’s fair to know that. An attack spread across thousands of different addresses, each with only a few attempts, can stay under the thresholds and never trigger a block; the same goes for “slow” attacks stretched out over time. And above all, no block based on failed attempts helps against credential stuffing that guesses the right password on the first try: there, the only real safety net is the second factor.

That’s the central point: there’s no single tool that solves the problem. It’s the sum of the layers - strong credentials, MFA, limits on attempts, and blocking abuse - that turns a brute force attack into little more than noise.

In summary

A brute force attack is the automated attempt to guess credentials by trying many of them quickly. Every exposed service receives them, because the attacks are automated, cheap, and indiscriminate. The basic defenses are few and reinforce one another: long, non-reused passwords (better still, cryptographic keys on servers), multi-factor authentication, limits on attempt frequency, and tools like fail2ban that block persistent addresses. None of these is enough on its own. Together, they turn a serious problem into a manageable nuisance.

Sources

• Brute force attack - OWASP
• Blocking Brute Force Attacks - OWASP
• Authentication Cheat Sheet - OWASP
• Credential stuffing - OWASP
• Fail2Ban - official project repository