Weak passwords and responsible brute-force testing — Web and application pentesting: understanding vulnerabilities

The login page is the front door of an application. If the lock is weak, nothing behind it matters. In this lesson you will see why passwords remain the first thing a tester examines, how guessing attacks work in principle, and how to test an application’s resistance to them safely, in your lab only.

Lab only

Guessing passwords against a real service is an offence, even against your own account on a site you do not own, because it targets someone else’s system without permission. It can also lock out real users and overload servers. Every exercise in this lesson is performed against your own training application. In a professional engagement, password-guessing tests are only done if the rules of engagement explicitly allow them, with agreed limits on speed and volume.

What goes wrong with passwords

Passwords are secrets that humans must invent and remember, which is why they fail in predictable ways. Attackers do not need magic; they rely on three weaknesses.

Weak choices. Short passwords, common words, keyboard patterns, a name followed by a year. Lists of the most common passwords circulate widely, and they cover a surprising share of real accounts.
Reuse. The same password on several sites. When one site is breached, attackers try the leaked pairs elsewhere. This is called credential stuffing.
Missing defences. An application that allows unlimited attempts, answers differently depending on whether the account exists, or never alerts anyone, makes guessing easy.

Three kinds of guessing

Technique	Principle	What stops it
Brute force	Try many possibilities for one account	Long passwords, attempt limits, monitoring
Password spraying	Try a few very common passwords across many accounts, staying under lockout thresholds	Banning common passwords, detecting patterns across accounts
Credential stuffing	Try leaked email and password pairs from other breaches	Multifactor authentication, breach-aware password checks, unique passwords

Notice that the defences are different. A lockout after five failures stops brute force on one account but does nothing against spraying, which tries one password per account. A tester has to think about each case separately.

What to test on a login form

A good password-related test checks the application’s controls, not just whether a password is guessable. Walk through these questions in your lab.

1. Does the application reveal which accounts exist?

Submit the login form with a username that exists and one that clearly does not, using a wrong password in both cases. Compare the responses carefully: the visible message, the HTTP status, the response size and even the response time. If the messages differ (“unknown user” versus “wrong password”), the application allows user enumeration: an attacker can build a list of valid accounts before guessing anything. The correct behaviour is one identical, generic message such as “Invalid username or password”, in both the text and the timing as far as possible.

2. Is there any limit on attempts?

Submit a handful of wrong passwords for a test account in your lab. Does the application slow down, show a CAPTCHA, lock the account temporarily, or do nothing at all? Note which one. In Burp, you can send the login request to Repeater and resend it several times, or use the Intruder module, which automates requests with a list of values. The Community Edition throttles Intruder, which is fine for learning.

3. What does the password policy accept?

Try creating an account with a very short password or a very common one. A weak policy is a finding. Current guidance, such as the NIST digital identity recommendations, favours length over complicated composition rules, recommends checking new passwords against lists of known compromised or very common values, and advises against forcing regular password changes without a reason. Ten character-class rules produce Password1!; a long passphrase is both stronger and easier to remember.

4. Are default credentials still active?

Many devices and applications ship with default accounts. In your lab, DVWA and similar tools document theirs openly. In real systems, leaving defaults in place is a classic and serious configuration error, and checking the vendor’s documented defaults on an authorised target is a routine test.

How a safe test looks in practice

Here is the logic of a controlled test in the lab, without any target other than your own application:

Create a test account in your lab application with a known password.
Prepare a very small list of candidate passwords, perhaps five, that includes the real one.
Send the login request to Burp’s Intruder, mark the password field as the variable position, and load your list.
Run it and compare the responses: status code, length, redirection.
Identify which attempt behaves differently, which is the successful one, and record how many attempts the application tolerated without reacting.

Attempt  Password        Status  Length  Note
1        candidate-one   200     1520    login failed message
2        candidate-two   200     1520    login failed message
3        lab-password    302     0       redirect: success
4        candidate-four  200     1520    login failed message

Observing that the successful attempt differs in status or length is the whole principle. The real lesson for a tester is the absence of defences this reveals: no delay, no lockout, no alert. That is what you will report, not the password you found in your own lab.

What a good defence looks like

Rate limiting and progressive delays per account and per source, instead of permanent lockouts that let attackers lock out real users (a form of denial of service).
Generic error messages that do not reveal whether an account exists, on the login form and also on registration and recovery pages.
Strong policy: minimum length, a check against common and breached passwords, no arbitrary composition rules.
Multifactor authentication, which makes stolen passwords far less useful (we will look at its limits in lesson 4).
Secure storage: passwords stored as salted hashes using a slow algorithm designed for passwords, never in clear text or with a fast general-purpose hash.
Monitoring and alerts on unusual numbers of failures.

As a user, a password manager and a unique password per site neutralise most of this class of attack. The French national agency ANSSI and the cybermalveillance.gouv.fr platform publish clear practical guidance on passwords for the public.

Tip

When you report a weak-authentication finding, describe the missing control (“no attempt limit observed after 50 failed logins on the test account”) rather than demonstrating how many accounts you could have compromised. Evidence of absence of a defence is enough.

Your turn: assess the login controls of your lab

On your training application, write a short assessment of its login page by answering the four questions above: enumeration, attempt limits, password policy, default credentials. Use Repeater or Intruder with a very small list, only against your own lab accounts.

See a solution

Your assessment might read:

Login assessment - training application, low security level
1. Enumeration: different messages for unknown user and wrong password -> finding (medium)
2. Attempt limit: 20 failed attempts in a row, no delay, no lockout, no captcha -> finding (medium)
3. Password policy: accepted a 3-character password -> finding (low to medium)
4. Default credentials: documented by the project, still active -> expected in a training lab
Recommendation: generic message, rate limiting, minimum length plus common-password check, MFA

If you raise DVWA’s security level, compare how the behaviour changes, and read the secure code to see what the developers added.

Key takeaways

Passwords fail through weak choices, reuse and missing defences; credential stuffing exploits reuse.
Brute force, spraying and stuffing are different attacks that need different defences.
Test for user enumeration, attempt limits, policy strength and default credentials, in your lab only.
Modern guidance favours long passphrases, breached-password checks and MFA over complex composition rules.
Report the missing control, not a pile of compromised accounts.

Once a user is logged in, the application must remember who they are. That is the job of sessions and cookies, our next topic.