> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/web/authentication/username-enumeration-via-account-lock.md).
# Username Enumeration via Account Lockout
Username Enumeration via Account Lockout notes for PortSwigger Web Security Academy labs, including exploitation workflow, payload testing, Burp Suite validation, and remediation context.
### Username Enumeration via Account Lock
The application sets up an account lock after several failed attempts, but the logic is imperfect. It can be used to:
1. Find a valid user name.
2. Force your password brutally.
3. Go to his account page.
The lists provided are:
* The **locking of the account** occurs \*\* only if the username is valid\*\*.
* For non-existent users, even after several attempts, the behavior remains different (no real lock, same message/response).
* One can therefore distinguish an existing user from a non-existing user only by observing the answers.
#### 1. Detection of a Valid Username
1. Send login requests in **Intruder Mode** with the **Cluster Bomb** technique:
* A set of candidates for the username field.
* A set of passwords to cause several failures.
2. Configure a \*\* correspondence rule (regex)\*\* to filter the answers that contain the message:
* `Invalid username or password.`
* Analyse results:
* **Invalid** accounts maintain consistent behaviour.
* For a valid \*\* account\*\*, after a number of failed tests, the response changes (locking).
1. Looking at the answers, we notice that the user name **`akamai`** differs from the others and reveals this behavior related to account locking. / → \*\*`akamai` is identified as a valid user name. \*\*
#### 2. Gross Strength of Valid Account Password
1. Once `akamai` has been identified as a valid user, Intruder is restarted in **mode Sniper**:
* The username field remains attached to `akamai`.
* Only the **password** is used with the wordlist provided ( Authentication lab passwords ).
1. The responses are reviewed again, including:
* The \*\* HTTP status code\*\*.
* The body size of the answer.
* Absence or modification of error message.
2. When testing the **`chelsea`** password, the answer is different (e.g. \*\* HTTP code different\*\* from other attempts). / → It is deduced that the torque **`akamai` / `chelsea`** is correct.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/web/authentication/username-enumeration-via-account-lock.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
