Authentication failures

Core idea

A password is a secret the server can check. The failures are about how that check is implemented and about how people reuse secrets. Keep three ideas separate:

• Online guessing sends attempts to the live login. The server sees every try. Rate limits and lockout exist for this case. Spraying is the variant that tries a few common passwords against many accounts so that no single account trips a lockout. It is still online guessing.
• Credential stuffing uses passwords stolen from somewhere else, betting that people reused them. The defense is breached-password screening and multi-factor authentication, not a longer lockout alone.
• Offline cracking happens when a password database leaks. The attacker is no longer talking to your login. They are guessing against hashes. The defense was in how you stored the password: a slow, salted password hash. A fast hash is a design error you cannot rate-limit after the file is gone.

None of these definitions requires a word list, and this desk will not give you one. Academy labs that teach a login flaw will hand you the small set of values they want you to compare.

What to look for

• Different error text for “no such user” and “wrong password”
• A lockout that locks the account forever, or that does not exist
• A reset flow that reveals whether the account is real, or that lets you set a password with a guessable token
• A password change that does not ask for the current password
• Response timing that differs when the user exists, even if the text is the same
• A hash exposed through an error or a backup. At that point the conversation is storage, not the login form

In the lab / in Burp

Map the login and the reset flow with the lab’s own accounts. In Repeater, send one known-good attempt and one known-bad attempt. Compare status, body text, and timing. If the lab asks you to try a handful of values it listed, do that and stop. Intruder is optional and only with that short list.

Write which of the three ideas the lab was illustrating. If the flaw is “the reset token is the username,” say that. Do not build a personal dictionary in the repo.

Defensive controls

Store passwords with a slow, salted password hash. Use one generic failure message. Rate-limit by account and by source, without creating a lockout an attacker can use to freeze every user. Screen new passwords against breached-password lists on the server side. Add phishing-resistant MFA for anything valuable. Rotate session handles at login. Require the current password to change the password.

Common pitfalls

Mixing up the three attack ideas in an exam answer. Pasting leaked password dumps anywhere near a study repo. Treating lockout as the complete defense against stuffing. Measuring a timing gap once and calling it a user enumeration bug. Attacking a real login to “try a few passwords.”

From the learning path

The January 2026 learning-path notes draw the line this page uses and then stay on the password check.

Authentication is the visible question: who is this. Authorization is usually invisible: what may they do. Authentication runs first. A correct login does not answer the authorization question. That question is the access-control note.

Online guessing includes a dictionary of likely passwords, not only every possible string. People also bend a strict composition rule into a predictable shape, and a forced rotation often becomes a small edit of the previous password. Those habits are why a breached-password check and MFA matter more than a clever character rule.

Usernames also leak from public profiles, author names, and error text that distinguishes “no such user” from “wrong password.” The lab section already compares those two responses. Do not build a list of likely names in this repo.