Weak authentication

Before the clever token attacks, there is the blunt reality that a lot of authentication barely resists at all. Default passwords nobody changed, accounts that survive a thousand guesses, logins that tell an attacker exactly which usernames are real. This lesson is the assessment side of authentication: finding where the front door is simply weak.

Default and weak credentials#

Software ships with default accounts, admin/admin, root/root, admin/password, a vendor's documented default, and a surprising amount of it reaches production with those unchanged. Admin panels, routers, databases, monitoring dashboards, and the branded appliance the recon path fingerprinted for you are all common offenders.

So on any login you find, and especially on the admin panels and third-party products recon turned up:

• Try the documented defaults for that exact product (the fingerprint tells you which product, and its manual tells you the defaults).
• Try a short list of the most common combinations: admin/admin, admin/password, admin/<companyname>, test/test.
• Check for setup or seed accounts left enabled, demo, guest, svc, backup.

Finding a live default credential is a complete authentication bypass and a serious finding on its own, and it is exactly what an exam means by "test for default credentials and weak passwords."

Username enumeration: the leak before the guess#

Before brute forcing, attackers want to know which usernames exist, so they are not wasting guesses. Applications leak this constantly by behaving differently for a real account versus a fake one:

• Different messages: "no such user" vs "wrong password". Now you know which usernames are real.
• Different timing: a real account runs the password check (slow); a fake one returns instantly (fast). The delay tells you.
• Different behaviour elsewhere: the registration form says "email already taken"; the password-reset form says "we sent a link" for real accounts and "no account found" for others.

Note enumeration where you find it, it is a real, reportable weakness, but keep its impact honest: on its own it is usually low severity. Its value is as an enabler, giving the next step a list of confirmed targets.

Brute force and credential stuffing#

If an account survives unlimited guesses, its password is only as strong as the user chose, which is often not strong. Two flavours:

• Brute force / password spraying: try many passwords against an account, or (to dodge lockouts) one common password against many accounts. Tools like Hydra or Burp Intruder automate the guessing; a wordlist of common passwords does most of the work.
• Credential stuffing: take username/password pairs leaked from other breaches and try them here, betting that people reuse passwords. This needs no guessing at all, just reuse.

What you are really testing is whether the application defends against this:

• Is there a rate limit or lockout after a handful of failures? Test by making several bad attempts and watching for a slowdown, a CAPTCHA, or a lock.
• Can the limit be bypassed? By rotating the source IP (via X-Forwarded-For if the app trusts it), by targeting a different endpoint (a mobile API that skips the web limit), or by spraying across many accounts so no single one trips a per-account lock.
• Is there multi-factor authentication, and can it be skipped (a bug you will meet in the reset lesson)?

"No rate limiting on login" is a finding, but a modest one by itself; it becomes serious when you can chain it to an actual account takeover, a weak password you then guess, or a limit you fully bypass.

Keep it honest, and keep it legal#

This is the lesson where the scope line matters most, because brute force is loud, active, and can lock real users out.

• Only against targets you are authorised to test, and even then, read the program's rules, many bug bounty programs forbid automated brute force, or require you to prove the absence of rate limiting with a small, careful sample rather than an actual mass attack.
• Use your own test accounts. Prove a weak-password or missing-lockout finding by taking over an account you created, not a real user's.
• Never use real breached credentials against real accounts you do not own; that is unauthorised access, wherever the passwords came from.

On this Academy's labs you are free to experiment; on the wider internet, this is the technique that most easily crosses from testing into an offence, so treat the scope as the hard boundary it is.

Where this goes next#

A strong password does not help if the recovery flow hands the account to an attacker. The next lesson goes after password reset and account recovery, which is frequently the softest way into an account that otherwise authenticates well, and where a single flawed token can undo every other protection.