What Is a Brute Force Attack? And How to Protect Your App

A brute force attack is guessing — at scale. An automated program tries password after password (or key after key) until one works. It's crude, but cheap for attackers, and it succeeds against weak passwords and unprotected login forms every day.

The main kinds

Simple brute force

Try every combination: aaaa, aaab, aaac… Only practical against short passwords or when the attacker has a stolen password hash to test offline.

Dictionary attacks

Try common passwords and words: password123, qwerty, Summer2026!. Far more efficient, because people choose predictable passwords.

Credential stuffing

Take email/password pairs leaked from other sites' breaches and try them on yours. Because people reuse passwords, a meaningful fraction work. This is the most common real-world attack on login forms.

Password spraying

Try one common password against many accounts, staying under per-account lockout limits.

SSH and admin panel bots

Any server on the internet with SSH open sees constant automated login attempts within minutes of going online. Same for /wp-admin, /admin and database ports. (Fail2ban)

Defences for your app's login

1. Rate limiting

Limit login attempts per IP and per account — say, 5 attempts per minute per account. Return 429 Too Many Requests after that. This turns millions of guesses per hour into a handful. (What is rate limiting?, Implementing rate limiting)

2. Gradual lockouts or delays

After several failures, add increasing delays or a temporary lock, with an email to the account owner. Avoid permanent lockouts — attackers can use them to lock real users out.

3. Two-factor authentication

Even a correct stolen password isn't enough without the second factor. Offer it, and require it for admins. (Two-factor authentication)

4. Passkeys

Passkeys can't be guessed, reused or phished. Offering them removes passwords from the equation. (What are passkeys?)

5. Check against breached passwords

Reject passwords that appear in known breach lists at sign-up (services like Have I Been Pwned offer an API that doesn't reveal the password). This directly blunts credential stuffing.

6. Hash passwords properly

If your database ever leaks, attackers brute-force the hashes offline at enormous speed. Slow, salted algorithms — Argon2id or bcrypt — make that impractical. Never store plain or fast-hashed (MD5, SHA-1) passwords. (Password hashing explained)

7. Don't reveal which part was wrong

"Invalid email or password" — not "no account with that email" — so attackers can't build a list of valid accounts.

8. CAPTCHA after suspicious activity

Add a challenge after a few failures, or when traffic looks automated. (How to add a CAPTCHA)

9. Monitor

Alert on spikes of failed logins. A sudden flood is an attack in progress.

Defences for your server

• SSH keys only — disable password login entirely. (SSH keys explained, SSH hardening)
• Fail2ban — automatically bans IPs with repeated failures.
• Firewall — don't expose databases, Redis or admin tools to the internet. (UFW basics)

Using an auth provider

Services like Supabase Auth, Clerk and Auth0 include rate limiting, breached-password checks and bot protection. If you build login yourself — or an AI tool builds it for you — make sure these protections exist; they're often missing from generated code. (Add login to an AI-built app, Clerk vs Auth0 vs Supabase Auth)

---

EasySpawn servers come with the firewall, OS patching and SSL handled, and databases that are never exposed to the internet — fewer open doors for the bots to try. See how it works or join the waitlist.

Related: What Is Rate Limiting? · Two-Factor Authentication · Password Hashing Explained · fail2ban