1. What it is (very simple definition)

Authentication means proving who you are to a website or app.

๐Ÿ‘‰ Authentication vulnerabilities happen when a website fails to correctly verify a user's identity, allowing attackers to log in as someone else.

In short:

The app trusts the wrong person.

2. Why it exists (what problem it was created to solve)

Websites needed a way to:

  • Know who is logged in
  • Protect private data
  • Allow different users to see different things

So authentication was created to answer one simple question:

"Are you really who you claim to be?"

To solve this, apps use:

  • Username + password
  • OTPs
  • Tokens
  • Sessions
  • Cookies

3. How it works (browser โ†’ server, step by step)

Let's walk through a normal login flow.

Step-by-step flow

  1. You open the login page
  • Browser loads /login

2. You enter credentials

  • Username + password
  • Click "Login."

3. Browser sends a request

POST /login
username=binaryshield
password=Password@123

4. Server verifies

  • Is the username real?
  • Does the password match?
  • Is the account active?

5. Server creates a session

  • Generates a random session ID
  • Stores it server-side

6. The server sends session cookie

Set-Cookie: sessionid=abc123; HttpOnly

7. Browser stores the cookie.

  • Automatically sends it on every request

8. Server trusts the cookie

  • "This request is from BinaryShield."

๐Ÿ”‘ Authentication is done once, then remembered via cookies/tokens.

4. Two simple examples (easy to imagine)

Example 1: House key ๐Ÿ 

  • Your key = password
  • Door lock = authentication logic
  • If the lock opens for any key โ†’ vulnerability

Example 2: College ID card ๐ŸŽ“

  • The securitySecurity guard checks ID
  • If guard never checks photo, anyone can enter
  • That's broken authentication

5. Real-world example (modern app or API)

Example: Login API (mobile app/web)

POST /api/login
{
  "email": "user@gmail.com",
  "password": "password123"
}

If the server:

  • Accepts weak passwords
  • Doesn't limit login attempts
  • Reuses tokens
  • Trusts client-side values

โžก๏ธ Authentication vulnerability exists

Modern failures often happen in:

  • JWT tokens
  • OAuth logins
  • Password reset flows
  • OTP verification APIs

6. What can go wrong (misconfigurations)

Common authentication mistakes:

๐Ÿšจ Password issues

  • Weak passwords allowed
  • Default passwords not removed
  • No password rotation

๐Ÿšจ Login flow issues

  • No rate-limiting
  • No account lockout
  • No CAPTCHA

๐Ÿšจ Session/token issues

  • Predictable session IDs
  • Tokens never expire
  • Tokens not invalidated after logout

๐Ÿšจ Reset & OTP issues

  • OTP reusable
  • OTP not tied to user
  • Password reset token never expires

7. How attackers abuse it (basic โ†’ advanced)

๐Ÿ”ฐ Basic attacks

  • Credential stuffing
  • Reuse leaked passwords
  • Brute force
  • Try many passwords
  • Default credentials
  • admin/admin

โš™๏ธ Intermediate attacks

  • OTP brute force
  • Password reset token reuse
  • Session fixation

๐Ÿ”ฅ Advanced attacks

  • JWT manipulation
  • OAuth misbinding
  • Token replay
  • Authentication bypass via logic flaws

๐Ÿ’ก Most real-world auth bugs are logic issues, not crypto failures.

8. Where and how to test it manually in VAPT

๐ŸŽฏ Where to test

Focus on:

  • /login
  • /logout
  • /register
  • /forgot-password
  • /reset-password
  • /verify-otp
  • Token refresh endpoints

๐Ÿ› ๏ธ How to test (manual mindset)

1๏ธโƒฃ Login testing

  • Try invalid passwords
  • Observe error messages
  • Check response differences

2๏ธโƒฃ Rate-limit testing

  • Multiple login attempts
  • Same IP vs different IP
  • Same user vs different users

3๏ธโƒฃ Session handling

  • Reuse old cookies
  • Logout โ†’ reuse cookie
  • Login as user A โ†’ replace cookie โ†’ user B

4๏ธโƒฃ Password reset testing

  • Reuse reset token
  • Use token after password change
  • Use token for another user

5๏ธโƒฃ OTP testing

  • Reuse OTP
  • Change user ID but keep the OTP.
  • Brute-force OTP length

๐Ÿง  Always ask:

"What is the server trusting that it shouldn't?"

9. Common beginner misunderstandings & false positives

โŒ Misunderstanding 1

"Login page exists = vulnerability"

โœ… Reality:

  • The loginLogin page is normal
  • Weak logic is the issue

โŒ Misunderstanding 2

"401 Unauthorized = bug"

โœ… Reality:

  • 401 is expected for failed login
  • Vulnerability = unexpected access

โŒ Misunderstanding 3

"No CAPTCHA = high severity"

โœ… Reality:

  • No CAPTCHA alone โ‰  vulnerability
  • Combined with no rate-limit โ†’ real risk

โŒ Misunderstanding 4

"JWT visible = insecure"

โœ… Reality:

  • JWTs are designed to be readable
  • The issue is trusting manipulated JWTs

๐Ÿง  Key takeaways (think like a pentester)

  • Authentication is about trust
  • Vulnerabilities come from wrong assumptions
  • Manual testing beats automation
  • Logic flaws > tool findings
  • Always validate impact, not just behavior

Useful Links:

learn = https://www.strongdm.com/blog/authentication-vulnerabilities

lab = https://portswigger.net/web-security/authentication

checklist = https://github.com/Az0x7/vulnerability-Checklist/blob/main/Authentication/authentication.md

tools = https://hacking-tools-scripts.binaryshield.in/