liveBook · Manning

Brute-force attack

As explained in Grokking Web Application Security

A brute-force attack is an automated attack that repeatedly tries credential guesses or other candidate values until one succeeds.

A brute-force attack automates repeated credential guesses until a login succeeds. Attackers target accounts because compromised access can enable fraud, marketing scams, or identity theft. A login page therefore needs defenses that slow guessing, avoid revealing useful account information, and protect passwords if data is exposed. section 8.0 section 8.1

The basic attack tries username-and-password combinations and records successful responses. Exhaustively generating values is impractical, so attackers commonly supply tools such as Hydra with username and password lists from earlier leaks. Password reuse makes those lists useful across sites and can produce results quickly. section 8.1

Reduce the chance and value of successful guessing with layered controls:

  • Encourage long, less-guessable passwords. Length matters more than superficial symbol rules because each added character greatly expands the possible values; password-strength feedback can nudge better choices. section 8.6
  • Add a CAPTCHA to login, sign-up, and password-reset flows to distinguish ordinary users from simple automated tools. Keep CAPTCHA secret keys on the server. section 8.7
  • Rate-limit incorrect guesses with small, growing delays, such as exponential backoff. Prefer limits by IP address to reduce targeted account lockouts, while recognizing shared IPs and bot networks complicate the trade-off. section 8.8
  • Offer MFA and consider SSO through OAuth or SAML, then store inbound passwords as salted and peppered hashes using a strong function. section 8.17

User enumeration makes guessing cheaper

Different login messages can tell an attacker whether a username exists: “Incorrect password” confirms an account, while a different message signals none exists. A brute-forcing tool can collect the confirmed names and focus password guesses on them. Return the same response, such as “Invalid credentials,” for both cases; use similarly neutral acknowledgments on registration and password-reset pages. section 8.14

hydra -L /usr/share/wordlists/usernames.txt
     -p password example.com https-post-form
     "/login:^USER^&=admin&password=password:Incorrect password"

This Hydra command illustrates how a tool can detect usernames by treating a particular login response as evidence that a password guess was wrong but the account exists. section 8.14

CAPTCHAs deter simple automation but are not a complete barrier: visual challenges can be defeated by computer vision, machine learning, or human CAPTCHA farms. Rate limiting likewise deters simple attacks but can inconvenience legitimate users or be spread across many attacker IP addresses. Use these controls together rather than relying on one. section 8.7 section 8.8

Brute force also describes recovering an unknown input from a hash by trying many candidate inputs until one produces a matching hash. That use differs from login guessing, but both depend on making the candidate search large and expensive. section 3.2

How Grokking Web Application Security covers it

How deep it goes
Explains attack mechanics, wordlists, enumeration, CAPTCHA integration, and rate-limiting trade-offs without a formal threat model.
Examples
Uses Hydra wordlists, differentiated login errors, reCAPTCHA tokens, exponential backoff, and zxcvbn password-strength feedback.
What you can do after
Apply it via reCAPTCHA, rate limiting, uniform responses, stronger passwords, MFA, and secure password storage.
How it connects
Connects password complexity, CAPTCHAs, rate limiting, user enumeration, MFA, SSO, hashing, and timing attacks.

Also explained in

Compare how 2 books explain brute-force attack →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.