Authentication Vulnerability

Imagine a hotel where the front desk never bothers to check your ID before handing you a room key. Anyone who walks up and says "I'm in room 402" gets the key to room 402. No questions asked.

Sounds like a disaster waiting to happen, right? That's basically what happens inside a web application when authentication is broken.\

What Is Authentication, Really?

Before we get into what breaks, let's understand what's supposed to work. Security folks talk about a concept called IAAA, and it's easier than it sounds: Identification, Authentication, Authorization & Accountability

• Identification — You claim who you are. (I'm Sreerag.)
• Authentication — The system checks if that claim is actually true. (Prove it.)
• Authorization — Once you're verified, the system decides what you're allowed to do. (Okay, you can access your own files, but not the admin panel.)
• Accountability — The system keeps a record of what you did, so actions can be traced back to you later.

Think of a hotel again. Identification is telling the receptionist your name. Authentication is showing your ID to prove you're really you. Authorization is getting a keycard that opens only your room, not every room in the building. Accountability is the keycard log that shows exactly when you entered and left.

A lot of people mix up authentication and authorization, so here's the simplest way to remember the difference: authentication asks "who are you?" and authorization asks "what are you allowed to do?" One always comes before the other.

How Does Authentication Actually Work?

Systems verify your identity using one or more of these four factors:

• Something you know — a password, PIN, or the answer to a security question. Think of it like the secret password friends use to recognize each other.
• Something you have — your phone, a hardware security key, or an OTP generator. It's like needing both your house key and the correct address to get inside.
• Something you are — your fingerprint, face, iris, or voice. Just like unlocking your smartphone with Face ID or your fingerprint — your unique biological traits become the key.
• Something you do — the unique way you interact with a device, such as your typing rhythm, how you move your mouse, how you swipe on your phone, or even your walking pattern. A fun comparison is Tony Stark interacting with J.A.R.V.I.S. in the Iron Man movies, his gestures and voice commands make it feel as if the system recognizes him naturally. While that's dramatized for Hollywood, modern behavioral biometrics uses your unique habits and interaction patterns to help verify your identity behind the scenes.

When a system combines two or more of these factors say, a password and an OTP sent to your phone, that's called Multi-Factor Authentication (MFA). It's like a hotel asking for your ID and a fingerprint scan before handing over the key. One factor being compromised isn't enough anymore.

When Authentication Breaks

Now here's where it gets interesting for attackers. Authentication mechanisms fail in a couple of common ways:

1. Broken authentication due to logic flaws or poor coding. Sometimes the code itself has a mistake, maybe a password reset link doesn't expire, or a session token isn't properly invalidated after logout. The lock exists, but it's built wrong.

2. Weak credentials and poor brute-force protection. This is when the system doesn't stop someone from guessing passwords or OTPs over and over. No lockout, no rate limiting, no CAPTCHA, just an open door that never gets tired of being knocked on.

A Real-World Example

In 2019, a security researcher named Laxman Muthiyah discovered a flaw in Instagram's password recovery feature. When a user requested a password reset, Instagram sent a six-digit code to their email or phone, one code out of a million possible combinations.

Normally, rate limiting should stop someone from guessing all million combinations. But Muthiyah found he could get around that limit by sending guesses from many different IP addresses at once, exploiting a race condition in how the requests were processed. In testing, he was able to try around 200,000 of the million possible codes before the system caught on, enough to prove that, with enough machines, an attacker could take over almost any account without the owner clicking a single malicious link.

Instagram fixed the flaw and awarded him a $30,000 bug bounty. But the lesson stuck: a six-digit code sounds secure, until you realize a computer can guess through all of them in a matter of hours if nothing stops it.

Why This Is So Dangerous

Authentication sits at the very front door of a system. That's exactly why broken authentication is treated as a critical severity issue in almost every vulnerability scoring system, including CVSS. A few reasons why:

• It's usually easy to spot during a pentest, you just try logging in wrong a hundred times and see what happens.
• Once bypassed, there's nothing left to stop the attacker. No second gate, no backup guard. They're already inside as you.
• The impact is often total account takeover, private messages, personal data, payment info, everything.

That combination of easy to find and catastrophic if found is exactly what pushes CVSS scores for these bugs into the high or critical range, broken authentication issues commonly land somewhere around 8.1 to 9.8 out of 10, depending on exactly how much access the flaw hands over.

How It's Prevented

The fixes aren't exotic, just consistently applied:

• Rate limiting and account lockouts after repeated failed attempts.
• Multi-factor authentication so a leaked password alone isn't enough.
• Strong password policies (length over complexity, checked against breach databases).
• Secure session and token handling so old sessions can't be reused.

Let's See It in Action

Theory is great, but let's actually break something. Here's how this plays out across two PortSwigger Academy labs, we'll break authentication two completely different ways: one by guessing our way in, and one by simply walking around the second lock entirely.

Lab 1: Username Enumeration via Different Responses

The target is a completely normal-looking login page,just a username field, a password field, and a login button. Nothing on the surface suggests anything is wrong.

To see what's really happening under the hood, we open Burp Suite and turn its Proxy on. Think of Burp as a checkpoint that sits between your browser and the website, every request your browser sends, and every response the server sends back, passes through it first, so you can inspect (and even edit) that traffic before it goes anywhere.

With the proxy capturing traffic, we submit one test login: username hacker, password hacked. It fails, obviously, but that's not the point. The point is we now have a real, complete copy of what a login request looks like, sitting in Burp's history.

We take that captured request and send it to Intruder, Burp's automation tool. Instead of typing "wrong username, try again" a hundred times by hand, Intruder lets us fire the same request over and over with one part swapped out each time, like a robot arm that keeps trying different keys on the same lock, thousands of times a minute.

In the Positions tab, we mark the username value as the part that should change on every request (Burp shows this with § symbols around it), and set the attack type to Sniper, meaning it cycles through a list of values one at a time in that single position.

Then, in the Payloads tab, we load a wordlist provided in the lab, about a hundred candidates in total. Every one of them gets fired at the login form automatically.

Here's the clever part. Almost every response comes back with the exact same status code (200), and at first glance the results table looks completely uniform, request after request, nothing standing out.

But keep scrolling, and one entry breaks the pattern: the username apollo comes back with a response length that's slightly different from every other row. That tiny difference is the tell: the server is unintentionally responding differently when a username actually exists, even though the login itself still fails. We've just found a valid username without ever seeing a yes, this account exists message written anywhere.

From here, the exact same trick gets pointed at the password field instead. We set up a fresh Intruder attack, this time marking the password value as the payload position and keeping the confirmed username fixed, then load a wordlist of common passwords and run another Sniper attack.

Just like before, most attempts return the same generic failure response, except one, which stands out with a different status code, revealing the correct password. That successful combination logs us in and solves the lab. TRY IT OUTTTT !!

The scary part isn't the toolinG, it's why this works at all. The application never printed "username not found." It didn't have to. A one-byte difference in response length was enough to leak that information, because nothing was normalizing the responses or rate-limiting the guesses. This is exactly the weak protection against brute force category of broken authentication we talked about earlier, just seen from the attacker's side of the screen.

Lab 2: 2FA Simple Bypass

The second lab attacks authentication from a completely different angle, no Burp Suite needed this time, just a browser and a habit of actually reading the URL bar.

The setup: this login form looks ordinary, but it has an extra step. After you enter a correct username and password, the app doesn't log you straight in it asks for a 4-digit security code as a second factor, sent to your email. That's Multi-Factor Authentication doing exactly what it's supposed to do… in theory.

We start by logging in with our own valid credentials(given in the lab). Sure enough, instead of landing on the account page, we get redirected to a second screen asking for that 4-digit code, at a URL ending in /login2.

Take a moment to observe the URL after you're redirected to the second login page. Once you enter your credentials, a verification code is sent to your registered email. Click the Email Client button to open your inbox, retrieve the code, and enter it to complete the login process. As you do this, pay close attention to how the URL changes, as it reveals an important part of how the authentication flow works.

Notice the URL carefully, it now reads my-account?id=wiener , indicating that you're currently viewing Wiener's account. This seemingly small detail becomes the key to the attack. In the next step, we'll leverage this behavior to demonstrate how an attacker can bypass the target user's two-factor authentication (2FA) by manipulating the account identifier.

After entering the victim's valid username and password, the application sends the 2FA verification code to the victim's email. Since we don't have access to their inbox, we can't retrieve the code. This is where the URL flaw we observed earlier comes into play, we'll exploit that weakness to bypass the second authentication step without needing the victim's verification code.

Here in the URL we enter the targets name.

Then we get the complete access to the target account just by editing the URL.

Notice this isn't a brute-force problem at all, it's the other category of broken authentication we covered earlier: a logic flaw. Nothing here was guessed or cracked. The developers built a second door (the 2FA screen) but forgot to actually lock the first one behind it, so anyone who knows the shape of the URL can just walk around the second door entirely.

Key Takeaway

A building can have the strongest walls in the world, but none of that matters if the front door doesn't actually check who's walking in, or if there's a second, unlocked door around the side that nobody remembered to guard. Lab 1 showed what happens when the front door will let anyone keep knocking forever. Lab 2 showed what happens when a second lock exists but was never actually wired to anything. Different mistakes, same result: authentication isn't just one security feature among many, it's the one that everything else depends on. Get it wrong, and every other control you built becomes irrelevant.