Lab 05 — Authentication, Session and Account Security Testing

Welcome to:

Lab 05 — Authentication, Session and Account Security Testing

This is the final Bug Bounty Hunter lab in this sequence.

In Lab 04, you mapped:

Users

Roles

Objects

Features

Requests

APIs

Workflow States

Security Boundaries

You now understand how NovaCloud works.

The next step is to test one of the most important boundaries in the entire application:

Identity

Every authorization decision depends on the application correctly answering:

Who Is
Making This Request?

Authentication and session security determine whether a user can safely move through:

Unauthenticated
      ↓
Authenticated
      ↓
MFA Verified
      ↓
Authorized Session
      ↓
Logout / Revocation

Your mission is to assess this lifecycle using only:

Researcher-Controlled Accounts

Researcher-Controlled Sessions

Training Data

Minimal Necessary Validation

Mission Information

Your Role

You are operating as a:

Bug Bounty Hunter

Application Security Researcher

continuing the fictional:

NovaCloud Security Research Program

Your primary testing surfaces are:

app.novacloud.test

auth.labs.novacloud.test

api.novacloud.test

You will assess:

Registration

Login

Session Creation

Session Rotation

Logout

Password Change

Password Reset

Recovery

Token Lifecycle

Authentication State

Mission Objective

By the end of this lab, you should be able to answer:

How Does NovaCloud
Establish Identity?

How Is a Session Created?

How Long Does It Last?

What Happens After Logout?

What Happens After
Password Change?

How Are Reset Tokens
Created and Invalidated?

Can Authentication States
Be Skipped or Reused?

Lab Objectives

By completing this lab, you will learn how to:

• map the complete authentication lifecycle.

• identify session cookies and bearer tokens.

• distinguish session identifiers from application data.

• establish authentication baselines.

• compare pre-login and post-login state.

• validate session rotation.

• assess logout behavior.

• assess session invalidation.

• test password-change effects on active sessions.

• map password-reset workflows.

• validate reset-token expiry.

• validate reset-token single use.

• assess token binding.

• assess account recovery.

• identify MFA state boundaries where available.

• detect stale authentication state.

• test concurrent sessions safely.

• distinguish client logout from server revocation.

• document authentication findings.

• create reproducible evidence.

• define and follow stop conditions.

• produce a professional authentication assessment summary.

Prerequisites

You should have completed:

Lab 01 — Build Your Professional Bug Bounty Research Environment

Lab 02 — Bug Bounty Program Scope Analysis and Target Prioritization

Lab 03 — Reconnaissance and Attack Surface Mapping

Lab 04 — Web Application Mapping and Security Boundary Analysis

You should also understand:

HTTP

Cookies

Bearer Tokens

Sessions

Authentication

Authorization

Password Reset

MFA Concepts

Lab Deliverables

By the end of this lab, create:

01 Authentication_Flow_Map.md

02 Authentication_Endpoints.csv

03 Session_Register.csv

04 Token_Lifecycle_Map.md

05 Authentication_State_Map.md

06 Login_Test_Matrix.csv

07 Logout_Test_Matrix.csv

08 Password_Change_Test_Matrix.csv

09 Password_Reset_Map.md

10 Password_Reset_Test_Matrix.csv

11 Session_Revocation_Matrix.csv

12 Authentication_Candidates.csv

13 Evidence_Register.csv

14 Authentication_Assessment_Summary.md

Part 1 — Prepare Controlled Accounts

Use:

Account A

Account B

from the previous labs.

For this lab, Account A will be the primary authentication-testing account.

Account B may be used only where a second controlled identity is useful.

Do not use:

Unknown Users

Customer Accounts

Employee Accounts

Part 2 — Prepare Clean Browser Sessions

Create:

Browser Session A

Browser Session B

You can use:

Separate Browser Profiles

Private Windows

Separate Containers

The goal is to maintain:

Independent
Authentication State

Part 3 — Create Authentication Flow Map

Create:

01 Authentication_Flow_Map.md

Begin with:

Visitor
      ↓
Registration
      ↓
Verification
      ↓
Login
      ↓
Session Creation
      ↓
Authenticated Application
      ↓
Logout

Also map:

Forgot Password
      ↓
Reset Request
      ↓
Reset Token
      ↓
Password Change
      ↓
Login

If MFA exists:

Password Verified
      ↓
MFA Pending
      ↓
MFA Verified
      ↓
Authenticated Session

Part 4 — Identify Authentication Endpoints

From the proxy history, identify endpoints related to:

Registration

Login

Logout

Password Change

Password Reset

Recovery

MFA

Token Refresh

Create:

02 Authentication_Endpoints.csv

Use:

Function	Method	Endpoint	Auth Required	State Change
Login	POST	/auth/login	No	Creates session
Logout	POST	/auth/logout	Yes	Ends session
Password Change	POST	/account/password	Yes	Changes credential
Reset Request	POST	/auth/reset	No	Creates reset flow
Reset Completion	POST	/auth/reset/confirm	Token	Changes credential

Use actual lab endpoints if different.

Part 5 — Establish Unauthenticated Baseline

Before login, capture a harmless authenticated-only request such as:

GET /api/v2/profile HTTP/1.1
Host: api.novacloud.test

Expected result:

401 Unauthorized

or equivalent.

Save:

baseline-unauthenticated-request.txt

baseline-unauthenticated-response.txt

Part 6 — Capture Login Request

Log in normally as:

Account A

Capture the request.

Document:

Username / Email Field

Password Field

Additional Parameters

CSRF Token

Device Data

Headers

Do not save the real password in your evidence package.

Part 7 — Identify Authentication Result

Observe whether successful login returns:

Set-Cookie

Access Token

Refresh Token

Redirect

Session Identifier

Create:

03 Session_Register.csv

with:

Session	Account	Mechanism	Created	Status	Notes

Example:

| SESSION-A1 | Account A | Cookie | Login | Active | Browser A |

Part 8 — Identify Cookie Properties

If cookies are used, record:

Secure

HttpOnly

SameSite

Domain

Path

Expiration

Do not assume a missing attribute automatically proves a bounty-worthy issue.

Record it as:

Security Observation

until impact is understood.

Part 9 — Identify Bearer Tokens

If the application uses:

Authorization:
Bearer <TOKEN>

record:

Where Token Is Received

Where Token Is Sent

Whether Refresh Token Exists

Token Expiration

Redact token values.

Part 10 — Create Token Lifecycle Map

Create:

04 Token_Lifecycle_Map.md

Example:

Login
      ↓
Access Token
      ↓
Authenticated Requests
      ↓
Refresh
      ↓
New Access Token
      ↓
Logout
      ↓
Expected Revocation

Part 11 — Authentication State Map

Create:

05 Authentication_State_Map.md

Possible states:

Unauthenticated

Credentials Submitted

Authenticated

MFA Pending

Password Reset Pending

Password Changed

Logged Out

Session Revoked

Part 12 — Why Authentication State Matters

Security failures can occur when the application confuses:

Partially Authenticated

with:

Fully Authenticated

or:

Logged Out

with:

Still Server-Side Valid

Part 13 — Session Rotation Test

Before login, record the pre-authentication session identifier if one exists.

Then:

Login
      ↓
Compare Session

Question:

Did the
Authentication Session
Change?

Part 14 — Session Fixation Concept

A secure application generally should avoid allowing an attacker-controlled or pre-authentication session to remain unchanged across authentication in a way that creates session-fixation risk.

For the lab:

Pre-Login Session
      ↓
Login
      ↓
Post-Login Session

Record whether the identifier rotates.

Do not attempt to involve another user’s session.

Part 15 — Create Login Test Matrix

Create:

06 Login_Test_Matrix.csv

Use:

Test	Expected	Observed	Result
Valid credentials	Login succeeds
Invalid password	Login denied
Missing password	Validation error
Post-login session rotation	Session changes
Authenticated profile access	Allowed

Part 16 — Invalid Login Behavior

Perform only a few controlled invalid login tests against:

Your Own Account

Do not perform:

Password Spraying

Credential Stuffing

High-Volume Guessing

The program explicitly prohibits password spraying.

Part 17 — Username Enumeration Observation

Compare responses for controlled cases such as:

Known Research Email

Synthetic Nonexistent Email

Look for differences in:

Message

Status

Timing

Response Structure

Do not perform bulk account enumeration.

Part 18 — Enumeration Is Contextual

A response difference such as:

User Does Not Exist

may create an enumeration signal.

But severity depends on:

Program Policy

Application Context

Authentication Design

Resulting Security Impact

Record it as a candidate, not automatically as a finding.

Part 19 — Authenticated Baseline

After login, repeat:

GET /api/v2/profile

Expected:

200 OK

This confirms:

Session A1
      ↓
Represents Account A

Part 20 — Logout Workflow

Capture the normal logout request.

Example:

Account A
      ↓
POST /auth/logout
      ↓
Browser Redirects
      ↓
Login Screen

But the important question is:

Did the Server
Actually Revoke
the Session?

Part 21 — Client Logout vs Server Logout

Client-only behavior:

Delete Cookie
      ↓
Show Login Page

does not necessarily prove:

Server-Side
Session Revocation

Part 22 — Save the Pre-Logout Session

Before logout, save a redacted copy of:

Session A1

or preserve the request containing it inside your proxy history.

Then perform normal logout.

Part 23 — Reuse Session After Logout

Using the previously captured researcher-owned session, repeat a harmless request such as:

GET /api/v2/profile

Expected:

Unauthorized

If the old session still works:

Potential
Session Revocation
Issue

Stop after one harmless controlled request.

Part 24 — Create Logout Test Matrix

Create:

07 Logout_Test_Matrix.csv

Use:

Test	Expected	Observed	Status
Normal logout	Session ends
Old session after logout	Denied
New browser request	Login required
Account data after logout	Unavailable

Part 25 — Logout Stop Condition

Define:

If the old session
successfully accesses
one harmless Account A
resource after logout,

capture evidence
and stop.

Do not continue accessing multiple resources.

Part 26 — Concurrent Session Setup

Log in as Account A in:

Browser A

Browser B

You now have:

Session A1

Session A2

Record both.

Part 27 — Concurrent Session Questions

Ask:

Are Multiple Sessions Allowed?

Does Logout from A1
Terminate A2?

Should It?

Does the Application
Offer "Log Out All Devices"?

Not every application needs logout to destroy all other sessions.

Evaluate against intended behavior.

Part 28 — Password Change Baseline

With:

Session A1

Session A2

active, change the password through the legitimate account settings.

Record:

Password Change Endpoint

Current Password Requirement

Session Used

Result

Part 29 — Test Old Session After Password Change

After password change, test:

Session A1

Session A2

with a harmless profile request.

Document whether:

Both Remain Valid

Only Current Session Remains Valid

All Sessions Are Revoked

Part 30 — Security Expectation

Whether every session should terminate after password change depends on the application’s security design.

However, sessions remaining active can become significant when password change is intended to recover from:

Account Compromise

Document actual behavior and business context.

Part 31 — Create Password Change Test Matrix

Create:

08 Password_Change_Test_Matrix.csv

Use:

Test	Expected	Observed	Notes
Correct current password	Change allowed
Incorrect current password	Denied
Session A1 after change	Defined behavior
Session A2 after change	Defined behavior
Old password login	Denied
New password login	Allowed

Part 32 — Old Password Verification

After password change:

Attempt Login
with Old Password

using only Account A.

Expected:

Denied

Then test the new password.

Expected:

Allowed

Part 33 — Password Reset Mapping

Now map the password reset workflow.

Create:

09 Password_Reset_Map.md

Example:

Reset Request
      ↓
Account Identifier
      ↓
Reset Token Generated
      ↓
Token Delivered
      ↓
Token Submitted
      ↓
Password Changed
      ↓
Token Invalidated

Part 34 — Reset Request Baseline

Using Account A:

Request Password Reset

Record:

Request Endpoint

Response Message

Delivery Method

Timestamp

Part 35 — Reset Response Enumeration

Compare:

Account A Email

Synthetic Nonexistent Email

using only a minimal number of requests.

Secure workflows often return similar messages such as:

If an account exists,
instructions have been sent.

Record observed differences.

Part 36 — Reset Token Properties

When the training environment exposes the researcher-owned reset token, document:

Length

Format

Delivery Channel

Expiration

Whether Token Is URL-Based

Whether Token Appears Single Use

Do not publish the live token.

Part 37 — Reset Token Single-Use Test

Use the Account A reset token normally.

After successful password reset, attempt to reuse the same token.

Expected:

Rejected

Part 38 — Reset Token Stop Condition

If the token can be reused:

Capture One
Controlled Reuse

against Account A and stop.

Do not repeatedly change the password.

Part 39 — Reset Token Expiration

If the lab provides a short test expiry, verify behavior:

Fresh Token
      ↓
Valid

Expired Token
      ↓
Rejected

Do not wait excessively in a real program solely to test this unless worthwhile and permitted.

Part 40 — Generate Two Reset Tokens

Using Account A:

Request Token R1

Request Token R2

Ask:

Does Creating R2
Invalidate R1?

The correct behavior depends on design, but allowing many simultaneously valid reset tokens can increase attack surface.

Part 41 — Reset Token Binding

A reset token should apply to:

The Intended
Account

In a dedicated lab, determine whether:

Token R1 for Account A

can be altered or combined with:

Account B Identifier

Do not test against unrelated accounts.

Part 42 — Create Password Reset Matrix

Create:

10 Password_Reset_Test_Matrix.csv

with:

Test	Expected	Observed	Result
Reset known account	Flow initiated
Reset nonexistent account	Safe response
Valid token	Accepted
Used token	Rejected
Expired token	Rejected
Older token after new token issued	Defined behavior
Token/account mismatch	Rejected

Part 43 — Password Reset and Existing Sessions

After resetting the password for Account A, test previously active researcher-controlled sessions.

Ask:

Are Existing Sessions
Revoked?

This matters because password reset often represents:

Account Recovery

Part 44 — Create Session Revocation Matrix

Create:

11 Session_Revocation_Matrix.csv

with:

Event	Session A1	Session A2	Expected Security Goal
Logout A1	Revoked	Depends	End selected session
Password Change	Test	Test	Protect changed credentials
Password Reset	Test	Test	Recover account
Account Disable	If lab supports	If lab supports	Remove access

Part 45 — Authentication Recovery Principle

A recovery workflow is weak if:

Attacker Session
Remains Valid

after the legitimate owner performs an action intended to regain control.

This is why:

Password Reset

Password Change

Device Removal

Session Revocation

should be analyzed together.

Part 46 — MFA Mapping

If NovaCloud’s training environment supports MFA, map:

Login
      ↓
Password Correct
      ↓
MFA Challenge
      ↓
MFA Verification
      ↓
Authenticated Session

Part 47 — MFA Pending State

Identify whether the application creates a state such as:

MFA_PENDING

The critical question is:

What Can This
Session Access?

Part 48 — Safe MFA Test

Using only Account A, while the session is:

MFA Pending

attempt one harmless authenticated request such as:

GET /api/v2/profile

Expected:

Denied

if MFA is required for full authentication.

Part 49 — Do Not Brute Force MFA

Do not perform:

OTP Brute Force

Large Code Enumeration

High-Rate Resends

unless a dedicated training lab specifically exists for it.

Part 50 — MFA Recovery

If available, map:

Lost Device

Backup Code

Recovery Email

Support Recovery

Ask:

Is Recovery
Weaker Than
MFA?

Again, use controlled training scenarios only.

Part 51 — Session Expiry

Observe:

Cookie Expiration

Token exp Claim

Refresh Behavior

Idle Timeout

Do not assume client-side expiry guarantees server-side rejection.

Part 52 — Expired Token Validation

If a training token naturally expires:

Expired Token
      ↓
Harmless API Request

Expected:

Denied

Part 53 — Refresh Token Flow

If refresh tokens exist, map:

Access Token Expires
      ↓
Refresh Token
      ↓
New Access Token

Record:

Refresh Endpoint

Authentication Requirement

Token Rotation

Revocation Behavior

Part 54 — Refresh Token Rotation

A secure design may rotate refresh tokens.

Conceptually:

Refresh Token R1
      ↓
Used
      ↓
R2 Issued
      ↓
R1 Invalidated

Whether rotation exists depends on design.

Document observed behavior.

Part 55 — Token Storage Observation

Record where the browser appears to keep authentication state:

HttpOnly Cookie

Memory

Local Storage

Session Storage

Do not automatically report local storage use without demonstrating relevant risk.

Part 56 — Remember Client Storage Is Context

The question is not:

Is Token
in Local Storage?

alone.

Ask:

What Can Access It?

Which Threat
Does This Enable?

What Other Controls
Exist?

Part 57 — CSRF Context

If authentication relies on automatically sent cookies, record whether state-changing requests appear to use:

CSRF Tokens

SameSite Cookies

Origin / Referer Validation

Full CSRF testing may be performed separately if included in the path.

Part 58 — Account Email Change

If the lab supports email-address changes, map:

Current Account
      ↓
Request Email Change
      ↓
Verification
      ↓
New Identity Attribute

Questions include:

Is Current Password Required?

Is Old Email Notified?

Is New Email Verified?

Part 59 — Sensitive Account Changes

Other security-sensitive account changes may include:

Password

Email

MFA

Recovery Information

API Keys

These deserve stronger authentication controls than cosmetic settings.

Part 60 — Reauthentication

Observe whether NovaCloud requires reauthentication before:

Password Change

Email Change

MFA Disable

API Key Generation

Record behavior.

Do not assume absence automatically means a vulnerability; evaluate impact.

Part 61 — Authentication Candidate Register

Create:

12 Authentication_Candidates.csv

Use:

ID	Observation	Security Question	Evidence	Status

Possible observations:

Old Session Works
After Logout

Reset Token Reusable

Reset Token Not Invalidated

MFA-Pending Session
Accesses Profile

Password Reset Leaves
Old Sessions Active

Part 62 — Candidate vs Finding

Remember:

Observation
      ↓
Candidate
      ↓
Reproduce
      ↓
Identify Broken Control
      ↓
Assess Impact
      ↓
Confirmed Finding

Part 63 — Validate Only What Is Needed

Suppose:

Old Session
Still Works
After Logout

You do not need to:

Download Files

Create Projects

Access Secrets

One controlled profile request is enough to demonstrate:

Session Remains
Authenticated

Part 64 — Build Evidence Package

For a confirmed candidate create:

09-Evidence/
└── AUTH-001/
    ├── 01-baseline-request.txt
    ├── 02-baseline-response.txt
    ├── 03-security-event.txt
    ├── 04-test-request.txt
    ├── 05-test-response.txt
    └── 06-timeline.md

Part 65 — Evidence Timeline Example

10:00
Logged in as Account A.

10:02
Captured Session A1.

10:05
Logged out normally.

10:06
Reused Session A1
for GET /api/v2/profile.

10:06
Server returned authenticated
Account A profile.

Part 66 — Redaction

Before saving evidence replace:

Cookie: session=abcdef...

with:

Cookie: session=<REDACTED_SESSION_A1>

Do the same for:

Reset Tokens

Access Tokens

Refresh Tokens

Passwords

Part 67 — Validate the Broken Security Boundary

For a session issue:

Logged Out
      ↓
Should Be
Unauthenticated

If the session remains valid:

Logout Boundary
Failed

Part 68 — Root Cause Thinking

Potential root causes include:

Client Deletes Token
but Server Does Not Revoke

Session Store
Not Invalidated

Reset Token
Not Marked Used

Old Credential State
Remains Trusted

MFA State
Not Enforced Server-Side

Part 69 — Observed Impact

Example:

A previously authenticated
session remains authorized
after the user logs out.

Part 70 — Potential Impact

Potential:

If an attacker had previously
obtained that session, the user
could not terminate the attacker's
access through normal logout.

Do not claim account takeover unless the full attack path is established.

Part 71 — Severity Context

Authentication severity depends on:

Attacker Preconditions

Session Theft Requirement

Persistence

Recovery Impact

Sensitive Function Access

User Interaction

Do not assign severity based only on:

Authentication Bug

Part 72 — Example Candidate: Reset Token Reuse

Observed:

Account A uses
Reset Token R1
successfully.

Then:

R1 Works Again

Broken control:

Single-Use
Token Enforcement

Part 73 — Example Candidate: Stale Session

Observed:

Password Reset
Completed

but:

Old Session A2
Still Authenticated

Question:

Does NovaCloud
Intend Password Reset
to Revoke Existing Sessions?

Understand the intended recovery model before severity assessment.

Part 74 — Example Candidate: MFA State

Observed:

Password Accepted

MFA Not Completed

but:

Profile API
Returns 200

Potential broken control:

Authentication
State Enforcement

Part 75 — Example Candidate: Enumeration

Observed:

Existing Account:
"Password Incorrect"

Unknown Account:
"Account Not Found"

Potential capability:

Account Existence
Discovery

Assess according to program policy and context.

Part 76 — Authentication Test Order

Recommended sequence:

1. Login Baseline

2. Session Identification

3. Session Rotation

4. Logout

5. Concurrent Sessions

6. Password Change

7. Password Reset

8. Session Revocation

9. MFA

10. Recovery

Part 77 — Why This Order Works

You first understand:

How a Session
Is Created

before testing:

How It
Should End

Then you examine:

Recovery
and
Revocation

as part of one lifecycle.

Part 78 — Create Evidence Register

Create:

13 Evidence_Register.csv

with:

Evidence	Test	Account	Purpose	Redacted

Example:

| AUTH-E01 | Logout reuse | Account A | Prove stale session | Yes |

Part 79 — Create Authentication Assessment Summary

Create:

14 Authentication_Assessment_Summary.md

Use:

# Authentication Assessment Summary

## Target

NovaCloud

## Assets

- app.novacloud.test
- auth.labs.novacloud.test
- api.novacloud.test

## Accounts

- Account A
- Account B

## Authentication Mechanism

Document observed mechanism.

## Workflows Assessed

- login
- session creation
- logout
- password change
- password reset
- session revocation
- MFA if available
- account recovery if available

## Session Model

Document:

- session mechanism
- token/cookie location
- expiration
- rotation
- refresh behavior

## Key Security Boundaries

1. Unauthenticated → Authenticated
2. MFA Pending → Fully Authenticated
3. Authenticated → Logged Out
4. Old Password → New Password
5. Reset Pending → Recovered Account

## Confirmed Secure Behaviors

-

## Vulnerability Candidates

-

## Confirmed Findings

-

## Evidence

-

## Overall Conclusion

-

Part 80 — Common Mistake: Test Unknown Users

Avoid:

Account Enumeration
Across Thousands
of Addresses

Use:

Research Account

Synthetic Nonexistent Account

only as needed.

Part 81 — Common Mistake: Treat Browser Logout as Proof

Seeing:

Login Screen

does not prove:

Session Revoked

Validate server behavior.

Part 82 — Common Mistake: Ignore Multiple Sessions

Authentication is not always:

One User
      =
One Session

Modern users may have:

Laptop

Phone

Tablet

API Client

Understand how security events affect all sessions.

Part 83 — Common Mistake: Brute-Force Controls

Do not turn authentication testing into:

High-Volume
Credential Attacks

especially when program rules prohibit them.

Part 84 — Common Mistake: Reset Real Users

Never initiate account recovery for:

Customers

Employees

Unknown Accounts

Use your own accounts.

Part 85 — Common Mistake: Reuse Live Tokens in Reports

Evidence should contain:

<REDACTED_TOKEN>

not reusable authentication material.

Part 86 — Common Mistake: Assume Every Missing Reauth Is a Bug

Reauthentication requirements depend on:

Risk of Action

Current Authentication

Session Age

Product Design

Assess impact.

Part 87 — Common Mistake: Ignore Intended Behavior

For example:

Password Change
Does Not Kill
Other Devices

may be intentional.

But:

Password Reset
Does Not Terminate
Known Compromised Sessions

may have different security implications.

Context matters.

Part 88 — Common Mistake: Overstate Account Takeover

If you prove:

Username Enumeration

do not claim:

Full Account Takeover

without an actual connected attack path.

Part 89 — Authentication Quality Checklist

Before completing the lab confirm:

Authentication Flow Mapped

Endpoints Identified

Session Mechanism Identified

Pre/Post Login Compared

Session Rotation Reviewed

Logout Tested

Old Session Tested

Concurrent Sessions Reviewed

Password Change Tested

Password Reset Mapped

Reset Token Reuse Tested

Reset Token Binding Reviewed

Existing Sessions Reviewed

MFA State Reviewed if Available

Evidence Redacted

Candidates Recorded

Stop Conditions Followed

Part 90 — Lab Success Criteria

You have successfully completed this lab when you can explain:

How NovaCloud
Establishes Identity

How Sessions
Are Created

How They Rotate

How They End

How Password
Changes Affect Them

How Password Reset
Changes Account State

How Recovery
Revokes Access

and

Which Authentication
Security Boundaries
Are Enforced

Portfolio Deliverables

Keep:

01 Authentication_Flow_Map.md

02 Authentication_Endpoints.csv

03 Session_Register.csv

04 Token_Lifecycle_Map.md

05 Authentication_State_Map.md

06 Login_Test_Matrix.csv

07 Logout_Test_Matrix.csv

08 Password_Change_Test_Matrix.csv

09 Password_Reset_Map.md

10 Password_Reset_Test_Matrix.csv

11 Session_Revocation_Matrix.csv

12 Authentication_Candidates.csv

13 Evidence_Register.csv

14 Authentication_Assessment_Summary.md

Portfolio Structure

Lab 05 — Authentication, Session and Account Security Testing
│
├── Authentication Flow
├── Endpoint Inventory
├── Session Register
├── Token Lifecycle
├── Authentication States
├── Login Testing
├── Logout Testing
├── Password Change Testing
├── Password Reset Testing
├── Session Revocation
├── Vulnerability Candidates
├── Evidence
└── Assessment Summary

Knowledge Check

1. What is authentication?

2. How is authentication different from authorization?

3. What is an authentication lifecycle?

4. What is a session?

5. What is a session identifier?

6. What cookie attributes are security-relevant?

7. What is an access token?

8. What is a refresh token?

9. Why should tokens be redacted?

10. What is authentication state?

11. Why can MFA-pending state be security-sensitive?

12. What is session rotation?

13. What is session fixation conceptually?

14. Why should pre-login and post-login sessions be compared?

15. Why should login baselines be preserved?

16. What is username enumeration?

17. Why should enumeration testing be minimal?

18. Why is client-side logout not proof of session revocation?

19. How can logout revocation be validated safely?

20. What is a logout stop condition?

21. Why are concurrent sessions important?

22. What should be tested after password change?

23. Why should old-password login be checked?

24. What is a password-reset token?

25. Why should reset tokens expire?

26. Why should reset tokens generally be single use?

27. What does token binding mean?

28. Why might generating a new reset token invalidate an older one?

29. Why should password reset be considered part of account recovery?

30. Why should active sessions be considered after password reset?

31. What is session revocation?

32. What is an MFA authentication boundary?

33. Why should OTP brute forcing be avoided?

34. What is authentication recovery?

35. Why can recovery be weaker than primary authentication?

36. What is token expiration?

37. What is refresh-token rotation?

38. Why is token storage context-sensitive?

39. Why can cookie-based authentication introduce CSRF considerations?

40. Why are sensitive account changes important?

41. What is reauthentication?

42. What is an authentication candidate?

43. When does a candidate become a confirmed finding?

44. What is minimal necessary validation?

45. Why must authentication evidence be redacted?

46. What is observed impact?

47. What is potential impact?

48. Why should account takeover not be overstated?

49. What should an authentication assessment summary contain?

50. What defines successful authentication security testing?

Key Takeaways

Authentication testing is not simply:

Try Wrong Password

It is understanding:

Identity
      ↓
Authentication State
      ↓
Session
      ↓
Credential Change
      ↓
Recovery
      ↓
Revocation

Remember:

Login Success
      ≠
Secure Session

Login Screen
      ≠
Session Revoked

Password Changed
      ≠
Old Sessions Revoked

Reset Completed
      ≠
Recovery Complete

Token Exists
      ≠
Token Vulnerability

Different Error
      ≠
Account Takeover

The professional methodology is:

Map
      ↓
Baseline
      ↓
Authenticate
      ↓
Identify Session
      ↓
Test State Changes
      ↓
Test Revocation
      ↓
Validate Recovery
      ↓
Measure Impact
      ↓
Collect Evidence
      ↓
Stop

The core question is:

After Every
Security Event,

Does the Application
Still Trust Only
the Identities and
Sessions It Should?

Career Connection

Authentication and session testing skills are important for:

Bug Bounty Hunters

Application Security Engineers

Web Penetration Testers

Product Security Engineers

Security Researchers

Red Teamers

During an interview, you should be able to explain:

I assess authentication
as a lifecycle rather
than only testing login.

I first map registration,
login, MFA, password reset,
recovery and session creation.

I establish authenticated
and unauthenticated baselines,
identify the application's
session or token mechanism
and document its lifecycle.

I then use researcher-owned
sessions to validate security
events such as logout,
password change and password
reset.

For each event, I determine
whether previously issued
authentication state remains
valid and whether that behavior
matches the intended security
model.

Where a weakness is identified,
I perform only the minimum
controlled request required
to prove the failed boundary,
redact authentication material
and document the resulting
security impact.

Labs Complete

You have now completed the planned:

Bug Bounty Hunter Labs

The sequence is:

Lab 01
Professional Bug Bounty
Research Environment

      ↓

Lab 02
Program Scope Analysis
and Target Prioritization

      ↓

Lab 03
Reconnaissance and
Attack Surface Mapping

      ↓

Lab 04
Web Application Mapping
and Security Boundary Analysis

      ↓

Lab 05
Authentication, Session
and Account Security Testing

These five labs establish the complete practical foundation:

Environment
      ↓
Scope
      ↓
Recon
      ↓
Application Understanding
      ↓
Controlled Security Testing

What’s Next?

➡️ Next: Bug Bounty Hunter Runbooks

The runbooks will now convert the full learning path and labs into reusable operational procedures.

Recommended runbook sequence:

Runbook 01 — Bug Bounty Program Intake and Scope Validation

Runbook 02 — Reconnaissance and Attack Surface Discovery

Runbook 03 — Web Application Security Assessment

Runbook 04 — Authentication and Session Security Assessment

Runbook 05 — Authorization and Access Control Assessment

Runbook 06 — API Security Assessment

Runbook 07 — Business Logic Security Assessment

Runbook 08 — Mobile Application Security Assessment

Runbook 09 — Cloud Bug Bounty Assessment

Runbook 10 — Vulnerability Validation and Evidence Collection

Runbook 11 — Vulnerability Reporting and Triage Communication

Runbook 12 — End-to-End Bug Bounty Research Engagement

The progression will therefore become:

Learning Modules
      ↓
Hands-On Labs
      ↓
Operational Runbooks
      ↓
Portfolio Projects
      ↓
Independent Bug Bounty Research

➡️ Next: Runbook 01 — Bug Bounty Program Intake and Scope Validation