HackproofHacks
Vulnerability walkthrough · Authentication

How to Exploit Broken Authentication: A Step-by-Step Lab Walkthrough

14 min read · Lab: DVWA

In one line

Broken authentication is when the login is weak enough to break: no limit on guesses, weak passwords, or flaws in reset and session handling, so an attacker can get in as someone else.

What this is, for a beginner

Authentication is how an application proves who you are, and broken authentication is the family of flaws that lets an attacker defeat or bypass that proof. It covers a lot of ground: no rate limiting so passwords can be brute-forced, weak or default credentials, predictable session tokens, and flawed password-reset flows that let one account take over another.

The most approachable example is a login form with no protection against repeated guesses. If the application accepts unlimited attempts and users choose weak passwords, an automated tool can simply try common combinations until one works. This is where tools like Burp Intruder and Hydra come in, and it is why rate limiting and multi-factor authentication matter so much.

The legal lab we use: DVWA

DVWA has a brute-force login page ideal for this. Run it locally so all credential guessing targets your own application.

DVWA project page →

Full walkthrough: exploiting it step by step

Step 1 — Open the DVWA brute-force page on Low

Set DVWA Security to Low and open the Brute Force login page. It accepts a username and password and gives a clear failure message, with no lockout.

Expected result: A login form that returns an incorrect message on failure and imposes no limit on attempts.

Step 2 — Capture a login attempt in Burp

Proxy through Burp, submit a wrong password, and capture the login request. Note the username and password parameters and the failure indicator in the response.

Burp — login request
GET /vulnerabilities/brute/?username=admin&password=wrong&Login=Login

Expected result: The request shows the credentials in parameters and the response contains a recognisable incorrect message.

Step 3 — Brute-force with Burp Intruder

Send the request to Intruder, mark the password as the payload position, load a small password list, and run it. Sort results by response length or by the presence of the failure string to find the hit.

Burp Intruder — password position
password=§password§   → payload list: rockyou-top-100.txt

Expected result: One request differs (different length, or no incorrect message), revealing the correct password for admin.

Step 4 — Automate with Hydra

The same attack from the command line uses Hydra, which is faster for large lists. Point it at your local DVWA login with the failure condition so it knows a wrong guess.

terminal
hydra -l admin -P rockyou.txt localhost http-get-form "/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect"

Expected result: Hydra reports the valid password once it finds the guess that does not return the incorrect message.

Step 5 — See defences on higher levels

Set security to Medium and High. Higher levels add delays and tokens that slow or block naive brute forcing, showing how rate limiting and anti-automation change the attack. Our Hydra guide covers the tooling in more depth.

Expected result: The same attack becomes far slower or fails, demonstrating why rate limiting and lockouts matter.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

  • Test whether the login, password reset, and one-time-code endpoints impose any limit on attempts; unlimited attempts is broken authentication by itself.
  • Check password-reset flows for predictable tokens, tokens that do not expire, or the ability to reset another user's password by changing an id.
  • Review session handling for predictable or non-rotating tokens and for sessions that survive logout or password change.

How to fix it

  • Enforce rate limiting and account lockout or progressive delays on authentication endpoints to stop automated guessing.
  • Require strong passwords, check them against known-breached lists, and offer multi-factor authentication so a guessed password alone is not enough.
  • Make reset tokens unpredictable, single-use, and short-lived, and tie them to the correct account server-side.
  • Rotate session tokens on login and privilege change, and invalidate them on logout and password change.

Common beginner mistakes

  • Using an enormous wordlist against a slow endpoint and waiting forever; start with a small, high-quality list.
  • Not identifying the failure condition precisely, so the tool cannot tell a success from a failure.
  • Ignoring reset and session flaws and focusing only on password guessing, when those are often the easier win.
  • Brute-forcing a login you are not authorized to test; keep it to DVWA or your own systems.

FAQ

Is brute forcing the only form of broken authentication?

No. It is the most visible, but broken authentication also covers weak or default credentials, predictable or non-expiring reset tokens, poor session management, and missing multi-factor authentication. Any of these can let an attacker authenticate as someone else.

Should I use Burp Intruder or Hydra?

Burp Intruder is great for HTTP logins you are already proxying and want to inspect closely; Hydra is faster for large lists and supports many protocols beyond HTTP. Learn both, since each fits different situations.

Does multi-factor authentication fix broken authentication?

It closes the biggest gap by ensuring a guessed or stolen password is not enough on its own, but it does not fix weak reset flows or poor session handling. Treat it as one essential layer among several.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

Keep practising