Authentication failures: where rate limits help and where they stop

Figures are from the A07:2025 page of the OWASP Top 10.

OWASP describes the category as any way an attacker can make a system accept the wrong user as legitimate.

• Automated sign-in attacks. Credential stuffing and password spraying with variations of leaked credentials, and brute force that is not stopped quickly.
• Weak or known passwords allowed. Including defaults, well-known passwords and passwords already found in breaches.
• Weak recovery. Knowledge-based answers that others can find or guess.
• Weak password storage. Plaintext, reversible encryption or fast hashes.
• Missing or weak multi-factor authentication. Including fallbacks that bypass it.
• Session flaws. Identifiers in URLs, identifiers reused after sign-in, sessions and tokens not ended at logout or after inactivity; see session hijacking.
• Credentials accepted for the wrong audience. A token whose scope and intended recipient are not checked.

A single sign-in attempt with a stolen password is indistinguishable from the owner signing in. What gives automation away is the aggregate: many attempts, many accounts, the same sources, failures at a rate no person produces.

OWASP's first scenario describes exactly that. Attackers take breached credentials, adjust them the way people adjust their own passwords, and try them at scale; an application with no defence answers each attempt and becomes an oracle for which guesses work. Credential stuffing covers the attack from the automation side.

The rest of the category leaves nothing in the request. A session that was never ended at logout, or a password stored with a fast hash, is a property of the application.

• Slow automated attempts. OWASP itself recommends throttling or progressively delaying failed sign-ins, without turning that into a way to lock out real users.
• Count by more than one subject. Many attempts from one place are caught by counting the source; one attempt each from many places is caught by counting the account being tried.
• Keep a record. Logging failed attempts and alerting on a suspected attack is part of OWASP's guidance, and a filter's log is one of those records.
• Stop at the boundary of the session. Once credentials are accepted, a filter sees an authenticated user making ordinary requests.

Choosing the subject of a limit covers the trade between counting by address and by account in detail.

• Multi-factor authentication. OWASP's first measure, and the one that blunts stuffing, brute force and reused credentials together.
• Better passwords without arbitrary rules. Check new passwords against the worst-passwords list and known breaches, follow NIST SP 800-63B on length and complexity, and do not force periodic rotation.
• No default credentials. Especially for administrators.
• Identical responses. Registration, recovery and sign-in answer the same way whatever the outcome, so accounts cannot be enumerated.
• A proven session manager. New high-entropy identifiers after sign-in, kept out of URLs, in secure cookies, ended at logout and after idle and absolute timeouts.
• Checked token audience. Validate issuer, audience and scope on every token.