05 Authentication Security Assessment

Mission Overview

Welcome to Lab 05 — Authentication Security Assessment.

In the previous labs, you mapped the application, analyzed HTTP traffic, and identified the endpoints and parameters that make up the application attack surface.

Now you will focus on one of the most important security boundaries in any web application:

Authentication

Authentication answers:

“Who are you?”

A weak authentication design can expose user information, allow password guessing, weaken account recovery, or create inconsistent access-control states.

This lab focuses on validating authentication controls in a safe, structured, evidence-driven way using only authorized test accounts and the intentionally vulnerable training application.

Mission Goal: Assess the application’s login, password policy, failure handling, account enumeration resistance, rate controls, account recovery, and authentication state transitions, then determine whether the controls provide reasonable protection against unauthorized access.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Authentication Security Testing
Secondary Skill	Identity Control Validation
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled Authentication Assessment
Primary Outcome	Authentication Security Assessment Report
Safety Level	Authorized Training Accounts Only

Learning Objectives

By completing this lab, you will be able to:

• map authentication workflows

• understand authentication state transitions

• compare valid and invalid login behavior

• assess login error consistency

• identify account enumeration signals

• evaluate password policy

• evaluate authentication rate controls

• evaluate account lockout behavior

• examine password reset workflows

• assess account recovery behavior

• observe MFA behavior where available

• distinguish authentication from authorization

• identify session establishment after login

• assess logout behavior

• identify risky authentication design patterns

• distinguish control weaknesses from confirmed bypasses

• assign severity and confidence

• collect authentication evidence

• produce a professional assessment report

Core Methodology

Use:

Map → Baseline → Compare → Validate Controls → Assess Impact → Evidence → Report

Expanded:

Authentication Surface
        │
        ▼
Map Login Workflow
        │
        ▼
Establish Normal Baseline
        │
        ▼
Compare Success / Failure
        │
        ▼
Assess Password Controls
        │
        ▼
Assess Enumeration Resistance
        │
        ▼
Assess Rate Controls
        │
        ▼
Assess Recovery Workflow
        │
        ▼
Assess MFA
        │
        ▼
Assess Logout / State
        │
        ▼
Validate Security Impact
        │
        ▼
Document Findings

The core principle is:

Authentication testing should determine whether identity controls fail—not simply whether an application behaves differently.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB05-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

ACCOUNT ROLES:

TEST WINDOW:

EXCLUDED SYSTEMS:

Use only authorized test identities.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-05/
    ├── 01-Scope/
    ├── 02-Authentication-Map/
    ├── 03-Login-Baseline/
    ├── 04-Failure-Behavior/
    ├── 05-Enumeration/
    ├── 06-Password-Policy/
    ├── 07-Rate-Controls/
    ├── 08-Lockout/
    ├── 09-Password-Reset/
    ├── 10-Recovery/
    ├── 11-MFA/
    ├── 12-Logout/
    ├── 13-State-Transitions/
    ├── 14-Evidence/
    ├── 15-Findings/
    └── 16-Report/

Part 3 — Map the Authentication Surface

Identify all authentication-related functionality.

Look for:

Login

Logout

Registration

Password Reset

Forgot Password

Account Recovery

MFA

Remember Me

Change Password

Change Email

Session Expiry

Create:

Function	Endpoint	Method	Public
Login	/login	POST	Yes
Logout	/logout	POST/GET	Authenticated
Password Reset	/forgot-password	POST	Yes
Change Password	/account/password	POST	Authenticated

Part 4 — Create the Authentication Workflow Map

Conceptually:

Anonymous User
     │
     ▼
 Login Page
     │
     ▼
Credentials Submitted
     │
     ├── Failure
     │
     └── Success
             │
             ▼
      Authenticated Session
             │
             ▼
           Logout

If password recovery exists:

Forgot Password
      │
      ▼
Account Identification
      │
      ▼
Recovery Verification
      │
      ▼
Password Reset
      │
      ▼
Authentication

Part 5 — Establish the Valid Login Baseline

Using an authorized test account, perform one normal successful login.

Record:

LOGIN BASELINE

Username:

Role:

Login Endpoint:

Method:

Status:

Redirect:

Response Message:

Session Created:
Yes / No

New Cookie / Token:

Destination After Login:

This becomes the reference for later comparisons.

Part 6 — Preserve the Successful Login Evidence

Capture:

• redacted request

• response

• timestamp

• redirect

• session state change

• destination

Assign:

EV-AUTH-001

Part 7 — Establish the Invalid Login Baseline

Use an authorized test username with an incorrect test password.

Record:

INVALID LOGIN

Username Valid:
Yes

Password Valid:
No

Response Code:

Response Message:

Response Length:

Redirect:

Session Created:
Yes / No

Delay:
Observed / Not Observed

Part 8 — Compare Valid vs Invalid Login

Create:

Attribute	Successful	Failed
Status
Message
Response Length
Redirect
Session Cookie
Timing

The objective is to understand the application’s authentication behavior.

Part 9 — Test an Invalid Username Safely

Use a clearly synthetic, non-existent lab identity such as:

ghc-no-user-9999

Use the same controlled test password.

Record:

INVALID USER TEST

Username Exists:
No

Response Code:

Response Message:

Response Length:

Redirect:

Timing:

Part 10 — Compare Invalid User vs Invalid Password

Create:

Attribute	Invalid User	Valid User + Wrong Password
Status
Message
Response Length
Redirect
Timing

Look for meaningful differences.

Part 11 — Understand Account Enumeration

Account enumeration occurs when an application reveals whether an account exists.

Example:

Unknown user:
"Account does not exist."

versus:

Known user:
"Incorrect password."

This may allow an unauthenticated person to identify valid accounts.

Part 12 — Look for Enumeration Signals

Possible signals include:

• different messages

• different response codes

• different response lengths

• different redirects

• clearly different behavior

• significant repeatable timing differences

One inconsistent response is not enough.

Validate repeatability.

Part 13 — Create the Enumeration Register

Test	Account Exists	Result	Difference
ENUM-001	Yes	Wrong password
ENUM-002	No	Unknown account

Assessment:

Account Enumeration:
Confirmed / Potential / Not Observed / Inconclusive

Part 14 — Avoid Overstating Timing Differences

Suppose:

Request A:
210 ms

Request B:
260 ms

This does not automatically prove enumeration.

Network and application timing naturally fluctuate.

Only consider timing meaningful when it is:

• repeatable

• substantial

• controlled

• attributable to account state with reasonable confidence

Part 15 — Assess Registration Enumeration

If self-registration exists, observe behavior when attempting to register:

Existing test username

versus:

New synthetic username

Record only behavior.

Do not create excessive accounts.

Part 16 — Assess Password Reset Enumeration

Password reset often leaks account existence.

Compare:

Known authorized test account

against:

Synthetic non-existent account

Example weak behavior:

Known:
"Reset email sent."

Unknown:
"No account exists."

Safer behavior may use a generic response such as:

"If the account exists, recovery instructions will be sent."

Part 17 — Assess Email-Based Enumeration

Also observe whether:

• response differs

• email delivery state is exposed

• user identifiers appear

• account metadata is revealed

Do not use real third-party email addresses.

Part 18 — Create the Enumeration Surface Matrix

Function	Enumeration Tested	Result
Login	Yes
Registration	If available
Password Reset	Yes
Account Recovery	If available

Part 19 — Assess Password Policy

Using only your authorized test account, identify the application’s password requirements.

Record:

PASSWORD POLICY

Minimum Length:

Maximum Length:

Complexity:

Character Restrictions:

Common Password Rejection:

Password History:

Username Similarity:

Password Change Requirements:

Observed / Documented:

Part 20 — Test Password Policy Safely

When the lab provides password-change functionality, use benign test values to determine whether expected policy controls are enforced.

Examples might include:

short test password

longer training password

simple alphabetic training password

Do not use leaked password lists or perform password cracking.

Part 21 — Evaluate Password Maximum Length

Applications should not unnecessarily restrict strong password use to very short lengths.

Record:

Maximum Accepted Length:

Observed Restriction:

Security Relevance:

Do not classify a maximum length automatically as a vulnerability without context.

Part 22 — Assess Password Change Workflow

Map:

Authenticated User
      │
      ▼
Change Password
      │
      ├── Current Password Required?
      ├── New Password
      └── Confirmation

Record:

CURRENT PASSWORD REQUIRED:
Yes / No

MFA REQUIRED:
Yes / No

NEW SESSION CREATED:
Yes / No

OLD SESSIONS INVALIDATED:
Yes / No / Unknown

Part 23 — Assess Rate Controls

Rate controls may limit repeated login attempts.

Using a small, controlled number of attempts against your authorized lab account, observe:

• increasing delay

• temporary denial

• CAPTCHA/challenge

• generic throttling

• account lockout

• IP/session throttling

Do not perform high-volume password guessing.

Part 24 — Use a Controlled Attempt Limit

For this training lab, use only enough attempts to observe the configured behavior.

For example:

Attempt 1
Attempt 2
Attempt 3
Attempt 4
Attempt 5

Stop if:

• lockout occurs

• service becomes unstable

• the lab instructions specify a lower threshold

• any unexpected operational effect appears

Part 25 — Build the Rate Control Register

Attempt	Result	Delay	Control
1	Failed
2	Failed
3	Failed
4	Failed
5	Failed

Final assessment:

Rate Limiting:
Observed / Not Observed / Inconclusive

Part 26 — Distinguish Rate Limiting from Lockout

Rate Limiting

Slows or rejects repeated authentication attempts.

Account Lockout

Temporarily or permanently prevents authentication for the account after a defined condition.

They are related but not identical.

Part 27 — Assess Account Lockout

If the training application has lockout controls, observe:

Threshold:

Lockout Duration:

User Notification:

Administrative Unlock:

Automatic Unlock:

Applies to:
Account / IP / Session / Unknown

Do not intentionally lock unrelated user accounts.

Part 28 — Consider Lockout Abuse Risk

Very aggressive account lockout may itself create operational issues because another person could repeatedly trigger:

Account Disabled

Therefore authentication design needs to balance:

Password Guessing Resistance
            +
Availability

Part 29 — Create the Authentication Control Matrix

Control	Present	Observed Behavior
Generic failures
Rate limiting
Lockout
MFA
Password policy
Recovery controls
Session regeneration

Part 30 — Assess Password Reset Workflow

Map:

Forgot Password
      │
      ▼
Account Input
      │
      ▼
Recovery Response
      │
      ▼
Recovery Token / Code
      │
      ▼
New Password

Record only the authorized test account flow.

Part 31 — Create the Password Reset Profile

PASSWORD RESET PROFILE

Endpoint:

Identifier Required:

Response Message:

Recovery Method:

Token / Code:
Observed / Not Observed

Token Delivery:
Lab Email / Training Interface / Other

Expiration:
Known / Unknown

Single Use:
Known / Unknown

Password Policy Applied:
Yes / No / Unknown

Existing Sessions Revoked:
Yes / No / Unknown

Part 32 — Assess Reset Token Handling

Without attempting to bypass security controls, observe:

• whether reset tokens appear random

• whether tokens are transmitted over the expected secure channel

• whether the token is exposed in URLs/log-friendly locations

• whether it can be reused after a successful reset

• whether expiration is visible in the lab behavior

Do not attempt guessing or high-volume token enumeration.

Part 33 — Test Single-Use Behavior

Using your authorized test account, after successfully completing a reset, verify whether the same previously used recovery link/code remains valid.

Record:

Token Reuse:
Accepted / Rejected / Not Tested

If rejected:

Positive Security Control:
Single-use behavior observed.

Part 34 — Assess Token Expiry Where Practical

If the training environment explicitly provides a short test expiry, observe whether an expired token is rejected.

Do not wait unnecessarily if the lab does not support this.

Use:

Expiry:
Verified / Documented / Unknown

Part 35 — Assess Password Reset Session Impact

After resetting the password, observe:

Existing Session:
Still Valid / Invalidated / Unknown

Other Authorized Test Session:
Still Valid / Invalidated / Unknown

This is relevant to incident recovery scenarios.

Part 36 — Assess Account Recovery

Applications may provide recovery through:

• email

• recovery codes

• support workflow

• MFA backup

• alternate identity verification

Map the mechanism.

Do not attempt social engineering against real people.

Part 37 — Build the Recovery Workflow Register

Step	Control	Observation
Identify account	Email/username
Verify ownership	Recovery mechanism
Reset access	Password/MFA
Session response	Revoke/retain

Part 38 — Assess MFA if Available

If the training application supports MFA, use only your authorized test identity.

Record:

MFA PROFILE

Enabled:
Yes / No

Authentication Factor:

Enrollment:

Challenge Timing:

Remember Device:

Backup Method:

Recovery Method:

Failure Behavior:

Part 39 — Understand Authentication Factors

Common factors include:

Something You Know
Password / PIN

Something You Have
Device / Token

Something You Are
Biometric

MFA generally combines different factor categories.

Part 40 — Assess MFA State Transitions

Map:

Username + Password
        │
        ▼
Primary Authentication Accepted
        │
        ▼
MFA Challenge
        │
        ▼
Authenticated Session

Ask:

At what point does the application actually create the fully authenticated session?

Part 41 — Observe Pre-MFA Session Behavior

If the training application uses a temporary state between password and MFA, document it.

Do not attempt to force bypasses in ways outside the lab scope.

Record:

PRE-MFA STATE

Cookie / Token:

Accessible Functions:

Full Authentication:
No

Notes:

Part 42 — Assess Remember-Me Functionality

If present, compare login behavior with:

Remember Me:
Disabled

and:

Remember Me:
Enabled

Record:

• whether cookie persistence changes

• whether session duration changes

• whether a separate token appears

Do not attempt token theft/replay beyond the authorized test workflow.

Part 43 — Assess Logout Behavior

Perform normal logout.

Record:

LOGOUT

Endpoint:

Method:

Response:

Redirect:

Session Cookie Changed:

Session Invalidated:
Yes / No / Unknown

Part 44 — Validate Post-Logout Access

After logout, revisit a previously authenticated page through normal browser navigation or a preserved benign request.

Record:

Post-Logout Access:

Authenticated Content Returned:
Yes / No

Redirected:
Yes / No

Session Accepted:
Yes / No

This verifies whether the session actually ended.

Part 45 — Distinguish Browser Cache from Active Session

A browser may visually display cached content after logout.

That does not necessarily mean:

Session remains valid

Verify with a fresh server request.

Part 46 — Assess Session Establishment

Compare:

Before Login Session

with:

After Login Session

Record whether the session identifier appears to change.

This supports later Lab 06 — Session Management Security Assessment.

Part 47 — Create the Authentication State Matrix

State	Expected Access
Anonymous	Public only
Password Accepted / MFA Pending	Limited/pre-auth
Authenticated User	User functions
Logged Out	Public only

Part 48 — Test Direct Access Baseline

Without authenticated state, request a known authenticated page using the normal authorized workflow.

Example:

/account

Record:

Response:

Redirect:

Authentication Required:

Content Exposed:

This is a baseline authentication-boundary check.

Part 49 — Distinguish Authentication from Authorization

Authentication:

Who are you?

Authorization:

What are you allowed to do?

A login page is primarily about authentication.

A user trying to access another user’s record is an authorization question and belongs mainly in Lab 07.

Part 50 — Assess Authentication Error Messages

Review:

• login failure

• locked account

• password reset

• invalid recovery

• MFA failure

Look for consistency and unnecessary account information disclosure.

Create:

Condition	Message	Information Exposure
Wrong password
Unknown account
Locked account
Reset unknown account

Part 51 — Assess Authentication Response Codes

Record whether the application uses:

200
302
400
401
403
429

where relevant.

Do not judge security based solely on the status code.

The complete behavior matters.

Part 52 — Assess Authentication Timing Carefully

If you notice repeatable timing differences, document:

Known Account Mean:

Unknown Account Mean:

Samples:

Difference:

Repeatable:
Yes / No

Confidence:

Do not use tiny variations as a finding.

Part 53 — Identify Positive Security Controls

Examples:

Generic authentication failures

Rate limiting

Temporary throttling

MFA

Single-use reset token

Reset-token expiration

Password policy

Session regeneration

Logout invalidation

Existing-session revocation after reset

Document what works.

Part 54 — Create the Positive Control Register

Control	Result	Evidence
Generic errors	Effective	EV-…
MFA	Effective	EV-…
Reset token reuse	Rejected	EV-…

Part 55 — Identify Potential Authentication Findings

Potential categories might include:

Account Enumeration

Weak Rate Controls

Inadequate Password Policy

Weak Recovery Process

Reset Token Reuse

Missing Session Invalidation

Authentication State Confusion

Do not create findings unless you validate security impact.

Part 56 — Finding Example: Account Enumeration

FINDING ID:
AUTH-001

TITLE:
Account Existence Disclosed Through Login Responses

SEVERITY:
Low / Medium
Based on context

CONFIDENCE:
High

ENDPOINT:
/login

OBSERVATION:
The application returned consistently different responses for
existing and non-existing accounts.

SECURITY IMPACT:
An unauthenticated user could determine whether candidate
usernames are registered.

EVIDENCE:
EV-AUTH-004
EV-AUTH-005

RECOMMENDATION:
Return consistent authentication failure responses regardless
of whether the submitted account exists.

Part 57 — Finding Example: Weak Rate Controls

FINDING ID:
AUTH-002

TITLE:
Authentication Endpoint Lacks Observable Request Throttling

CONFIDENCE:
Medium

OBSERVATION:
Within the authorized controlled attempt window, repeated
failed authentication attempts received equivalent responses
without observable delay or temporary restriction.

LIMITATION:
Testing intentionally remained low volume.

SECURITY IMPACT:
Weak rate controls may increase exposure to automated password
guessing.

RECOMMENDATION:
Implement layered authentication throttling and monitoring
appropriate to application risk.

Notice the wording.

Do not claim:

Unlimited brute force possible

when your test intentionally used only a few requests.

Part 58 — Finding Example: Password Reset Token Reuse

If verified:

FINDING ID:
AUTH-003

TITLE:
Password Recovery Token Remains Valid After Use

SEVERITY:
High
Depending on workflow and impact

CONFIDENCE:
High

OBSERVATION:
A recovery token successfully used to reset the authorized test
account remained accepted for another reset.

IMPACT:
Possession of a previously used recovery token could continue
to provide account recovery capability.

RECOMMENDATION:
Invalidate recovery tokens immediately after successful use.

Part 59 — Avoid False Findings

Do not report:

Login endpoint is public.

as a vulnerability.

Do not report:

Password field exists.

as a vulnerability.

Do not report:

Authentication uses cookies.

as a vulnerability.

These are normal application behaviors.

Part 60 — Build the Authentication Findings Register

Finding	Status	Severity	Confidence
Account enumeration
Weak rate controls
Password policy weakness
Recovery weakness
Session invalidation

Part 61 — Build the Authentication Coverage Matrix

Area	Tested	Result
Login	Yes
Failure messages	Yes
Enumeration	Yes
Password policy	Yes
Rate controls	Yes
Lockout	Yes/NA
Password reset	Yes
Recovery	Yes/NA
MFA	Yes/NA
Logout	Yes
State transitions	Yes

Part 62 — Create the Evidence Register

Capture:

Evidence ID	Description
EV-AUTH-001	Successful login baseline
EV-AUTH-002	Invalid password response
EV-AUTH-003	Invalid username response
EV-AUTH-004	Enumeration comparison
EV-AUTH-005	Rate-control observations
EV-AUTH-006	Password reset flow
EV-AUTH-007	Recovery-token behavior
EV-AUTH-008	MFA flow
EV-AUTH-009	Logout behavior

Part 63 — Mission Challenge

Complete:

AUTHENTICATION SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Test Accounts:

Roles:


AUTHENTICATION SURFACE

Login:

Logout:

Registration:

Forgot Password:

Password Reset:

Recovery:

MFA:

Remember Me:

Change Password:


SUCCESSFUL LOGIN

Endpoint:

Method:

Status:

Redirect:

Session Created:

Cookie / Token:


FAILED LOGIN

Valid User + Wrong Password:

Status:

Message:

Response Length:


Invalid User:

Status:

Message:

Response Length:


ACCOUNT ENUMERATION

Login:
Confirmed / Not Observed / Inconclusive

Registration:

Password Reset:

Recovery:

Evidence:


PASSWORD POLICY

Minimum Length:

Maximum Length:

Complexity:

Common Password Control:

Password History:

Change Password Control:


RATE CONTROLS

Attempts Performed:

Delay:

Throttling:

Temporary Restriction:

Rate Limit:
Observed / Not Observed / Inconclusive


LOCKOUT

Threshold:

Duration:

Unlock:

Availability Risk:


PASSWORD RESET

Identifier:

Response:

Token / Code:

Expiry:

Single Use:

New Password Policy:

Existing Session Revoked:


RECOVERY

Mechanism:

Ownership Verification:

Security Controls:


MFA

Enabled:

Factor:

Challenge:

Pre-MFA State:

Remember Device:

Backup / Recovery:


LOGOUT

Endpoint:

Session Invalidated:

Authenticated Page After Logout:


STATE TRANSITIONS

Anonymous:

Primary Authentication:

MFA Pending:

Authenticated:

Logged Out:


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


LIMITATIONS

Limitation 01:

Limitation 02:


FINAL ASSESSMENT

Authentication Bypass:
Confirmed / Not Observed / Inconclusive

Account Enumeration:

Rate Controls:

Password Controls:

Recovery Controls:

MFA Controls:

Logout Controls:

Overall Authentication Risk:

Ready for Session Management Assessment:
Yes / No

What Not to Do

Do not:

Perform high-volume password guessing

Use leaked credential lists

Attempt credential stuffing

Lock unrelated accounts intentionally

Test real users

Use third-party email addresses

Attempt MFA bombing

Attempt social engineering

Guess reset tokens at volume

Reuse credentials outside the lab

Perform destructive account changes

Confuse enumeration with account compromise

Confuse lack of rate limiting with proven password compromise

Confuse successful login with authorization to all functions

Store credentials in evidence unnecessarily

The professional rule is:

Validate authentication controls with the minimum interaction necessary to establish the security behavior.

Professional Distinctions

Always distinguish:

Authentication
      ≠
Authorization

Valid Username Identified
      ≠
Account Compromised

Account Enumeration
      ≠
Authentication Bypass

No Observable Rate Limit
      ≠
Successful Password Attack

Failed Login
      ≠
Account Attack Success

Account Lockout
      ≠
Strong Authentication Automatically

Password Reset Email Sent
      ≠
Password Reset Completed

Recovery Token Obtained
      ≠
Account Compromised Automatically

MFA Enabled
      ≠
MFA Bypass Impossible

HTTP 200
      ≠
Authentication Success

Redirect to Dashboard
      ≠
Authorized Access to Every Function

Logout Page Displayed
      ≠
Session Invalidated

Evidence Requirements

Capture:

• authorization and scope

• authentication surface map

• successful login baseline

• successful login response

• invalid password response

• invalid username response

• valid/invalid comparison

• enumeration register

• registration enumeration where applicable

• password-reset enumeration

• password-policy profile

• password-change workflow

• rate-control register

• lockout profile

• Authentication Control Matrix

• password-reset profile

• reset-token behavior

• recovery workflow

• MFA profile where applicable

• pre-MFA state where applicable

• remember-me observations

• logout evidence

• post-logout validation

• authentication state matrix

• error-message matrix

• positive controls

• findings register

• coverage matrix

• evidence register

Mission Deliverables

Complete:

• scope confirmed

• authentication surface mapped

• valid login baseline established

• failed login baseline established

• invalid account behavior tested

• valid vs invalid behavior compared

• account enumeration assessed

• registration enumeration assessed where applicable

• password-reset enumeration assessed

• password policy documented

• password change workflow reviewed

• rate controls assessed safely

• account lockout assessed where applicable

• password reset workflow mapped

• reset-token handling assessed

• reset-token single-use behavior assessed where available

• session impact after reset evaluated

• account recovery mapped

• MFA assessed where available

• pre-MFA state documented where applicable

• remember-me behavior reviewed

• logout behavior tested

• post-logout session validity checked

• authentication states mapped

• direct unauthenticated access baseline checked

• authentication error messages reviewed

• status-code behavior documented

• positive security controls documented

• findings validated

• limitations documented

• Authentication Security Assessment completed

Lab Report Template

# Lab 05 — Authentication Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## Authentication Surface

## Authentication Workflow

## Successful Login Baseline

## Failed Login Behavior

## Account Enumeration

## Registration Behavior

## Password Policy

## Password Change Workflow

## Rate Controls

## Account Lockout

## Password Reset Workflow

## Recovery Token Handling

## Account Recovery

## MFA Assessment

## Remember-Me Behavior

## Logout Assessment

## Authentication State Transitions

## Direct Authentication Boundary Checks

## Authentication Error Messages

## Authentication Control Matrix

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — What is authentication?

Authentication establishes the identity of a user or entity.

Question 2 — What is account enumeration?

A condition where application behavior reveals whether a particular account exists.

Question 3 — Does identifying a valid username mean the account is compromised?

No.

It only exposes account existence.

Question 4 — Does lack of visible rate limiting prove that brute force will succeed?

No.

It indicates a potentially weaker defensive control that may increase guessing exposure.

Question 5 — Why use generic authentication errors?

To reduce unnecessary disclosure about whether specific accounts exist.

Question 6 — Why should password-reset tokens become invalid after use?

To prevent previously used recovery material from continuing to grant recovery capability.

Question 7 — Does MFA automatically make authentication secure?

No.

The entire authentication and recovery workflow still requires assessment.

Question 8 — Why validate logout with a fresh request?

Because a browser may display cached content even when the server-side session has already ended.

Question 9 — What is the difference between authentication and authorization?

Authentication determines who the user is. Authorization determines what that user is permitted to access or perform.

Question 10 — What is the central question?

“Can an unauthorized user gain meaningful information about accounts, bypass expected authentication controls, or abuse account-recovery behavior within the authorized training application?”

Skills Achieved

After completing this lab, you should understand:

• authentication-surface mapping

• login workflow analysis

• successful and failed login comparison

• account-enumeration assessment

• password-policy assessment

• rate-control assessment

• lockout analysis

• password-reset assessment

• recovery-workflow assessment

• reset-token handling

• MFA workflow analysis

• authentication-state analysis

• remember-me behavior

• logout validation

• authentication-boundary assessment

• positive-control documentation

• authentication finding validation

• evidence-driven reporting

Professional Takeaway

A weak authentication assessment looks like:

Login Page
    ↓
Try Random Passwords
    ↓
No Success
    ↓
Authentication Secure

A professional assessment looks like:

Map Authentication Surface
        ↓
Establish Success Baseline
        ↓
Establish Failure Baseline
        ↓
Compare Account States
        ↓
Assess Enumeration
        ↓
Assess Password Controls
        ↓
Assess Rate Controls
        ↓
Assess Recovery
        ↓
Assess MFA
        ↓
Assess Logout
        ↓
Map Authentication States
        ↓
Validate Security Impact
        ↓
Evidence
        ↓
Report

What’s Next?

➡️ Lab 06 — Session Management Security Assessment

In the next lab, you will move from how the application authenticates a user to how it maintains that authenticated state after login.

You will assess:

• session cookies

• session identifiers

• session creation

• session regeneration

• login state changes

• cookie security attributes

• logout invalidation

• session expiry

• idle timeout

• concurrent sessions

• password-change session behavior

• password-reset session behavior

• remember-me tokens

• pre-auth vs post-auth sessions

• session evidence

The methodology becomes:

Create → Observe → Compare → Transition → Expire → Invalidate → Validate → Report

The central question will be:

“Once a user is authenticated, does the application maintain, rotate, expire, and invalidate session state in a way that prevents unauthorized reuse of that identity?”