Lab 07 Authentication Security Assessment

Mission Overview

Welcome to Lab 07 — Authentication Security Assessment.

In Lab 06, you identified and prioritized vulnerabilities across your authorized environment. Now we move to one of the most important areas of modern security:

Identity and Authentication

Organizations increasingly depend on identities rather than network location alone to determine who can access systems, applications, cloud platforms, and sensitive information.

A technically secure application can still be compromised if its authentication controls are weak.

In this lab, you will assess authentication controls using lab-provided accounts and intentionally weak training configurations. The objective is not uncontrolled password cracking. Instead, you will determine whether authentication controls appropriately protect access.

Mission Goal: Identify authentication surfaces, evaluate password and account controls, safely assess intentionally weak or default training credentials, review lockout and MFA controls, examine session behavior, and produce an Authentication Security Assessment.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	Authentication Security Assessment
Secondary Skill	Identity Security
Environment	Authorized Linux/Web Training Targets
Testing Type	Controlled Authentication Assessment
Primary Outcome	Authentication Security Register
Evidence Required	Observations + screenshots + assessment report
Safety Level	Authorized Lab Accounts Only

Learning Objectives

By completing this lab, you will be able to:

distinguish identification, authentication, and authorization
identify authentication surfaces
understand password-policy controls
recognize default and intentionally weak training credentials
assess authentication error handling
evaluate account-lockout controls safely
understand MFA security benefits
recognize anonymous and guest access
review authentication exposure
understand session-security fundamentals
identify credential-related security risks
assess authentication controls without uncontrolled credential attacks
classify authentication findings
recommend identity-security improvements
document authentication evidence professionally

Authentication Security Model

Use this model throughout the lab:

Identity
   ↓
Authentication
   ↓
Session
   ↓
Authorization
   ↓
Resource

Each layer answers a different question.

Identity

Who is requesting access?

Authentication

Can the user prove that identity?

Session

How is the authenticated state maintained?

Authorization

What is that identity permitted to access?

These concepts should not be treated as interchangeable.

Lab Architecture

Example:

                   GHC Ethical Hacking Lab
                       192.168.56.0/24
                              │
                         Kali Linux
                              │
              ┌───────────────┴───────────────┐
              │                               │
              ▼                               ▼
         Linux Target                     Web Target
              │                               │
         SSH / FTP                       Web Login
              │                               │
              ▼                               ▼
       OS Authentication             Application Identity

Use only systems and accounts explicitly provided for your training environment.

Part 1 — Confirm Authorization

Authentication testing can create account lockouts and audit events.

Before starting, record:

Authorized Targets:

Authorized Accounts:

Lab Credentials:

Permitted Authentication Tests:

Account Lockout Testing:
Allowed / Not Allowed

MFA Testing:
Allowed / Not Allowed

Excluded Accounts:

Stop Conditions:

Never use credentials belonging to real users or external systems.

Part 2 — Create the Lab Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-07/
    ├── Notes/
    ├── Evidence/
    │   ├── Web/
    │   ├── SSH/
    │   ├── Password-Policy/
    │   ├── Sessions/
    │   └── MFA/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-07-Investigation-Journal.md

Use:

# Lab 07 — Authentication Security Assessment

## Mission Objective

## Scope

## Authorized Accounts

## Authentication Surfaces

## Password Controls

## Default Credential Assessment

## Error Handling

## Account Lockout

## MFA

## Session Security

## Anonymous Access

## Findings

## Evidence

## Recommendations

## Lessons Learned

Part 3 — Understand Identification vs Authentication

Consider a web login:

Username:
student

Password:
********

The username provides:

Identification

The password provides evidence for:

Authentication

Successful login establishes:

Authenticated Identity

The application then determines:

Authorization

This gives us:

Identification → Authentication → Authorization

Part 4 — Identify Authentication Surfaces

Review the service inventory from Labs 04 and 05.

Look for services such as:

SSH

FTP

SMB

Web Login

Administrative Portal

Database Interface

API Authentication

Create an Authentication Surface Register:

ID	Target	Service	Port	Authentication
AUTH-01	TGT-01	SSH	22	Account
AUTH-02	TGT-01	FTP	21	Account/Anonymous
AUTH-03	TGT-01	SMB	445	Account/Guest
AUTH-04	TGT-02	Web App	80	Web Login

This establishes where identity controls exist.

Part 5 — Classify Authentication Methods

For each service, determine the observed authentication type.

Possible examples:

Username + Password

SSH Key

Anonymous Access

Guest Access

Session Cookie

MFA

API Token

Certificate

Do not assume every authentication surface uses passwords.

Modern environments increasingly use several authentication factors.

Part 6 — Understand Authentication Factors

Authentication factors are commonly divided into:

Something You Know

Password
PIN

Something You Have

Security Key
Authenticator Device
Smart Card

Something You Are

Fingerprint
Facial Recognition

MFA combines independent factors.

Conceptually:

Password
   +
Authenticator
   ↓
Stronger Authentication

Part 7 — Establish the Test Accounts

Use dedicated training accounts.

Example:

Account	Role	Purpose
lab-user	Standard User	Normal authentication
lab-admin	Administrator	Privileged authentication
weak-user	Training Account	Weak-password scenario
disabled-user	Disabled	Control validation

Do not add real personal credentials to your evidence.

Part 8 — Test Normal Authentication

Start with expected behavior.

Using the training application’s login interface:

Enter the authorized username.
Enter the correct lab password.
Authenticate.
Record the result.
Log out.

Record:

Account:

Authentication Result:

Landing Page:

Session Established:

Logout Available:

Observations:

This creates your known-good baseline.

Part 9 — Test an Incorrect Password

Use one intentionally incorrect password against the dedicated training account.

Observe:

response message
response behavior
failed-login notification
account state
logging if available

Example observation:

Username:
lab-user

Password:
Incorrect training value

Result:
Authentication denied.

This is controlled authentication testing, not brute forcing.

Part 10 — Examine Authentication Error Messages

Compare responses for:

Valid Username + Incorrect Password

and, if your lab permits it:

Nonexistent Training Username + Incorrect Password

Secure behavior generally avoids revealing unnecessary account-existence information.

Potentially weak behavior:

User does not exist.

versus:

Password incorrect for lab-user.

Different responses can reveal whether an account exists.

A more generic response might be:

Invalid username or password.

Part 11 — Understand Username Enumeration Risk

If authentication responses reveal whether usernames exist:

Attacker submits username
          ↓
Application response
          ↓
Valid / Invalid identity disclosed

This can assist later credential attacks.

Document:

Finding:
Authentication response may reveal account existence.

Evidence:
Different responses observed.

Security Relevance:
Potential username enumeration.

Validation:
Confirmed through dedicated lab accounts.

Part 12 — Review Password Policy

If your lab provides administrative visibility into password policy, record:

Minimum Length:

Complexity Requirements:

Password History:

Password Expiration:

Common Password Restrictions:

Lockout Threshold:

Lockout Duration:

MFA Requirement:

Do not change policy unless the mission explicitly permits it.

Part 13 — Evaluate Password Length

Password length is one of the important factors affecting password resistance.

Compare:

Weak:

lab123

with a stronger conceptual example:

Long, unique passphrase

Do not use examples from this course as real passwords.

Ask:

Does the system permit passwords that are unnecessarily short or predictable?

Part 14 — Assess the Intentionally Weak Training Account

If the lab includes a deliberately weak credential, use the credential supplied with the exercise.

For example:

Training Account:
weak-user

Training Password:
Provided by Lab

Authenticate once using the supplied credential.

Record whether:

login succeeds
MFA is required
account has unnecessary privileges
the credential violates expected policy

The lesson is not discovering passwords through guessing.

The lesson is understanding the impact of weak credential configuration.

Part 15 — Assess Default Credentials

Some training systems intentionally contain a documented default account.

If explicitly included in your lab instructions:

Default Training Account
        ↓
Attempt Authorized Login
        ↓
Record Result

Do not build lists of default credentials and test them across unrelated systems.

If the supplied default credential succeeds, document:

Finding:
Default credentials remain active.

Target:

Account:

Authentication Result:

Privilege Level:

Security Impact:

Do not include the actual password in your final report unless required by the controlled lab.

Part 16 — Understand Default Credential Risk

Default credentials are dangerous because they may be:

publicly documented
reused across deployments
predictable
forgotten after installation

The remediation is straightforward:

Change default credentials.

Disable unnecessary default accounts.

Require unique credentials.

Apply MFA where appropriate.

Monitor authentication activity.

Part 17 — Evaluate Anonymous Authentication

From Lab 05, you may already know whether services allow:

Anonymous FTP

Guest SMB

Unauthenticated Web Access

Review whether that behavior is intentional.

Example:

Service:
FTP

Anonymous Access:
Enabled

Content:
Training public files

Expected:
Yes

Finding:
Informational

Context matters.

Part 18 — Assess Guest Access

For an authorized training share, determine whether guest access exists.

Record:

Service:

Guest Access:

Authentication Required:

Resources Visible:

Read Access:

Write Access:

Expected Configuration:

Do not modify files unless specifically required.

Part 19 — Understand Account Lockout

Account lockout can reduce repeated password-guessing attempts.

Example policy:

Failed Attempts:
5

Action:
Temporary Lock

Duration:
15 minutes

But lockout also introduces availability considerations.

An attacker might intentionally trigger lockouts against users.

Security controls require balance.

Part 20 — Safely Test Lockout Behavior

Only perform this section if the lab explicitly allows it.

Use a dedicated disposable training account.

Do not automate the test.

Perform only the small number of failures required by the lab policy.

Example methodology:

Attempt 1 → Incorrect

Attempt 2 → Incorrect

Attempt 3 → Incorrect

Expected Lab Threshold Reached
           ↓
Stop

Never continue attempts after the objective is met.

Part 21 — Document Lockout Behavior

Record:

Attempt	Result	Account State
1	Failed	Active
2	Failed	Active
3	Failed	Locked

Then document:

Expected Threshold:

Observed Threshold:

Lockout Duration:

User Notification:

Administrative Event:

Result:

Part 22 — Understand Why Unlimited Attempts Are Dangerous

Without rate limiting or other controls:

Authentication
      ↓
Unlimited Attempts
      ↓
Increased Credential Attack Opportunity

Protective mechanisms may include:

rate limiting
temporary lockout
MFA
risk-based authentication
bot protection
monitoring
passwordless authentication

No single control solves every problem.

Part 23 — Review MFA

If the training application includes MFA, determine:

Which accounts require MFA?

Which authentication factor is used?

Does MFA apply to privileged accounts?

Is MFA required during new sessions?

Are recovery mechanisms protected?

Do not attempt to bypass MFA.

The objective is to assess whether the control exists and where it is applied.

Part 24 — Privileged Account Authentication

Administrative accounts deserve stronger controls.

Compare:

Control	Standard User	Administrator
Password	Yes	Yes
MFA	Optional	Expected
Restricted Source	Maybe	Preferred
Monitoring	Yes	Enhanced
Session Controls	Standard	Stronger

Ask:

Does the privileged account receive protection proportional to its impact?

Part 25 — Authentication Exposure

Suppose SSH authentication is available from every system on the lab network.

Ask:

Does every system require access to SSH?

Could the management interface be restricted?

Should administrative access come only from a management network?

Authentication security includes both:

Credential Strength

and:

Where authentication can be attempted from.

Part 26 — Review Unnecessary Authentication Surfaces

Suppose the target exposes:

SSH

FTP

Web Admin

Database Login

Each interface creates another place where credentials could potentially be attacked.

Ask:

Are all four authentication surfaces required?

Reducing unnecessary services reduces attack surface.

Part 27 — Observe Web Session Creation

Authenticate to the training web application.

Using your browser’s developer tools, observe how the application maintains the authenticated state.

You may see a session cookie.

Do not alter or steal sessions.

Simply document:

Session Created:
Yes

Cookie Observed:
Yes / No

Secure Attribute:
Observed / Not Observed

HttpOnly:
Observed / Not Observed

SameSite:
Observed / Not Observed

Part 28 — Understand Session Security

Authentication usually occurs once.

Afterward:

Login
  ↓
Authentication
  ↓
Session Established
  ↓
Requests Use Session

If session controls are weak, strong passwords alone may not adequately protect the application.

Session security therefore forms part of authentication assessment.

Part 29 — Test Logout Behavior

Using your own authorized session:

Log in.
Confirm access to an authenticated page.
Log out.
Attempt to revisit the authenticated page normally.

Expected behavior:

Authenticated Session
        ↓
Logout
        ↓
Session Invalidated
        ↓
Authentication Required

Record the result.

Part 30 — Session Timeout

If the training application has a configured short timeout, observe whether an inactive session expires as expected.

Record:

Expected Timeout:

Observed Timeout:

Reauthentication Required:

Result:

Do not artificially extend or hijack sessions.

Part 31 — Password Recovery Security

If the lab includes a dedicated password-recovery workflow, examine it from the normal user interface.

Ask:

Does recovery reveal whether an account exists?

Is identity verification required?

Does the process expire?

Is the recovery process protected from repeated requests?

Does recovery weaken MFA?

Do not target real email accounts or external services.

Part 32 — Review Authentication Over the Network

Ask whether credentials are transmitted over an appropriately protected channel.

For web authentication:

HTTP
vs
HTTPS

For remote administration:

Legacy clear-text protocol
vs
Encrypted protocol

A password can be strong while its transport mechanism is weak.

Part 33 — Build an Authentication Control Matrix

Create:

Control	Web	SSH	FTP	SMB
Authentication Required	Yes	Yes	Varies	Varies
Strong Transport	Review	Yes	Review	Review
Anonymous Access	No	No	Review	N/A
Lockout	Review	Review	Review	Review
MFA	Review	Review	N/A	Review
Session Controls	Yes	N/A	N/A	N/A

This gives you a system-wide view.

Part 34 — Classify Authentication Findings

Use categories such as:

Critical

A weakness could provide immediate unauthorized privileged access with substantial impact.

High

A serious authentication weakness affects an important or exposed system.

Medium

The weakness meaningfully reduces authentication protection but has mitigating controls.

Low

Limited security impact.

Informational

Useful observation without a demonstrated security weakness.

Severity should reflect evidence and context, not fear.

Part 35 — Finding Example: Default Credentials

Finding:
Default training credentials remain active.

Affected Asset:
TGT-02

Authentication Surface:
Administrative Web Interface

Observation:
The documented default training account successfully authenticated.

Impact:
An unauthorized party with knowledge of the default credential
could obtain the permissions assigned to the account.

Recommendation:
Disable unnecessary default accounts and require unique
credentials during deployment.

Part 36 — Finding Example: Username Disclosure

Finding:
Authentication responses reveal account existence.

Observation:
The application returns different responses for valid and
invalid usernames.

Impact:
The behavior may allow an attacker to identify valid account
names and improve subsequent credential attacks.

Recommendation:
Use consistent authentication failure responses and monitor
repeated account-discovery behavior.

Part 37 — Finding Example: Missing MFA

Do not automatically write:

MFA missing = vulnerability

First determine context.

A better analysis:

Asset:
Privileged administrative portal

Exposure:
Broad network access

Account:
Administrative

MFA:
Not required

Security Relevance:
Compromise of a password may directly expose privileged access.

Now the lack of MFA has meaningful context.

Part 38 — Finding Example: Weak Lockout Controls

Finding:
Authentication attempts are insufficiently restricted.

Evidence:
Dedicated lab account accepted the approved number of repeated
failed attempts without protective response.

Impact:
The authentication interface may provide insufficient resistance
to repeated credential attempts.

Recommendation:
Implement appropriate rate limiting, risk-based controls,
monitoring, MFA, and lockout protection where suitable.

Part 39 — Credential Reuse Awareness

Credential reuse creates risk because compromise of one account or service may affect another.

For this lab, do not test credentials from one service against multiple accounts or external systems.

Instead understand the defensive principle:

Every privileged or important account should use unique authentication material.

Part 40 — Authentication Logging

If your lab provides access to authentication logs, review your own test events.

Look for:

Successful Login

Failed Login

Account Lockout

Logout

Administrative Authentication

Correlate:

Your Test
   ↓
Application Event
   ↓
Security Log

This connects ethical hacking with SOC operations.

Part 41 — Build an Authentication Timeline

Example:

Time	Account	Event	Result
10:00	lab-user	Login	Success
10:05	lab-user	Incorrect Password	Failed
10:10	weak-user	Lab Credential	Success
10:20	lab-user	Logout	Success

This demonstrates how defenders see authentication activity.

Part 42 — Think Like Both Tester and Defender

Tester

Ask:

Which authentication control appears weak?

Defender

Ask:

Would monitoring detect attempts against that control?

This creates:

Security Weakness
      +
Detection Capability
      +
Response Capability
      =
Better Risk Understanding

Part 43 — Build the Authentication Security Register

Your primary deliverable should look like:

ID	Surface	Observation	Risk	Confidence	Recommendation
AUTH-01	Web Login	Username disclosure	Medium	Confirmed	Generic responses
AUTH-02	Admin Login	MFA absent	High	Confirmed	Require MFA
AUTH-03	FTP	Anonymous access	Medium	Confirmed	Restrict access
AUTH-04	Web Session	Logout invalidates session	None	Confirmed	Control effective
AUTH-05	Password Policy	Weak training password accepted	Medium	Confirmed	Strengthen policy

Notice that effective controls can also be documented.

Part 44 — Record Positive Security Controls

A professional assessment should not only look for weaknesses.

Record controls that work correctly.

Examples:

MFA enforced for administrators.

Generic login failure messages.

Account lockout operates correctly.

Session invalidated after logout.

HTTPS protects authentication.

Anonymous access disabled.

This produces a more balanced assessment.

Part 45 — Prioritize Authentication Risks

Use:

Privilege
   +
Exposure
   +
Authentication Weakness
   +
Missing Secondary Controls
   +
Potential Impact
   =
Priority

Example:

Admin Account
      +
Externally Reachable Login
      +
Weak Password
      +
No MFA
      =
High Authentication Risk

Several moderate weaknesses can combine into a serious attack path.

Part 46 — Create an Identity Attack-Surface Map

Example:

                         Target
                           │
              ┌────────────┼─────────────┐
              │            │             │
              ▼            ▼             ▼
             SSH         Web App        SMB
              │            │             │
              ▼            ▼             ▼
          OS Account    Web Account   File Access
              │            │             │
              └────────────┼─────────────┘
                           ▼
                       Identity Risk

This map will become increasingly useful during attack-path analysis.

Part 47 — Evidence Requirements

Capture:

Evidence 01

Authorized account list with passwords redacted.

Evidence 02

Authentication Surface Register.

Evidence 03

Successful normal authentication.

Evidence 04

Controlled failed authentication.

Evidence 05

Authentication error behavior.

Evidence 06

Password-policy configuration where available.

Evidence 07

Default/weak training credential result where provided.

Evidence 08

Anonymous or guest access assessment.

Evidence 09

Lockout behavior where explicitly authorized.

Evidence 10

MFA observation.

Evidence 11

Session-security attributes.

Evidence 12

Logout/session invalidation.

Evidence 13

Authentication logs where available.

Evidence 14

Final Authentication Security Register.

Part 48 — Mission Challenge

Determine:

Number of Authentication Surfaces:

Password-Based Services:

Anonymous Services:

Guest Access:

Default Training Accounts:

Weak Training Accounts:

MFA-Protected Accounts:

Privileged Accounts Without MFA:

Account Lockout:

Rate Limiting:

Username Disclosure:

Secure Authentication Transport:

Session Protection:

Logout Behavior:

Highest-Risk Authentication Surface:

Strongest Authentication Control:

Top Remediation Priority:

Every answer should be supported by evidence.

Part 49 — What Not to Do

This lab does not require:

Large password lists

Automated brute forcing

Credential stuffing

Password spraying

Credential theft

MFA bypass

Session hijacking

Testing leaked credentials

Testing real user accounts

The objective is to assess authentication controls, not generate large volumes of login attempts.

Part 50 — Troubleshooting

Lab Account Does Not Work

Confirm:

username
training password
correct application
account state
target address

Do not respond by trying many passwords.

Account Becomes Locked

Stop authentication attempts.

Document:

Account:

Number of Authorized Attempts:

Lockout Observed:

Time:

Recovery:

Follow the lab reset procedure.

Record the behavior.

Unexpected behavior is part of testing.

Do not manipulate the application beyond the authorized mission.

Check:

correct browser developer-tools section
authentication succeeded
whether another storage mechanism is used

Record Unknown if evidence is insufficient.

MFA Is Not Available

Do not simulate or invent it.

Record:

MFA:
Not Observed

Then determine whether MFA should reasonably be expected for that account and environment.

Mission Deliverables

Complete:

scope reconfirmed
authorized accounts documented
Authentication Surface Register created
normal authentication tested
controlled failure tested
authentication error behavior assessed
password policy reviewed
supplied weak/default training credentials assessed
anonymous access reviewed
guest access reviewed
lockout controls reviewed where authorized
MFA controls assessed
privileged authentication reviewed
session creation observed
logout behavior tested
authentication transport reviewed
authentication logs correlated where available
positive controls documented
findings prioritized
Authentication Security Register completed
remediation recommendations created
final report completed

Lab Report Template

# Lab 07 — Authentication Security Assessment

## Executive Summary

## Mission Objective

## Scope

## Authorized Accounts

## Authentication Architecture

## Authentication Surface Register

## Password Policy Assessment

## Default Credential Assessment

## Authentication Error Handling

## Anonymous and Guest Access

## Account Lockout and Rate Limiting

## MFA Assessment

## Privileged Authentication

## Authentication Transport

## Session Security

## Authentication Logging

## Positive Security Controls

## Security Findings

## Risk Prioritization

## Recommendations

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is authentication?

Authentication is the process of verifying that an identity is who or what it claims to be.

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

Authentication determines who you are.

Authorization determines what you are permitted to access or perform.

They may reveal whether a particular username or account exists.

Question 4 — Are default credentials always acceptable if the system is internal?

No.

Network location alone should not be relied upon to compensate for weak authentication.

Question 5 — Why is MFA particularly important for privileged accounts?

Because compromise of a password alone should not easily provide high-impact administrative access.

Question 6 — Is account lockout the only defense against password attacks?

No.

Controls can include MFA, rate limiting, monitoring, strong password policies, risk-based authentication, passwordless mechanisms, and appropriate lockout strategies.

Question 7 — Why test logout?

To verify that an authenticated session is properly invalidated when the user ends it.

Question 8 — Should every missing MFA implementation automatically be reported as a critical vulnerability?

No.

Risk depends on privilege, exposure, application sensitivity, compensating controls, and organizational requirements.

Question 9 — Why avoid uncontrolled password guessing?

It can lock accounts, disrupt users, create unnecessary traffic, exceed scope, and provide little additional value when the objective is simply to assess authentication controls.

Skills Achieved

After completing this lab, you should understand:

identity concepts
authentication vs authorization
authentication-surface mapping
password-policy assessment
weak/default credential risk
username-enumeration risk
anonymous authentication
guest access
account-lockout controls
rate-limiting concepts
MFA
privileged authentication
authentication transport
session-security fundamentals
logout validation
authentication logging
authentication risk prioritization
remediation planning
identity-security reporting

Professional Takeaway

Authentication testing should not be reduced to:

“Can I guess the password?”

A professional assessment asks:

“Where can identities authenticate, how are those identities verified, which controls protect them, how are failures handled, what happens after authentication, and what would the impact be if an account were compromised?”

Use:

Identity → Authentication Surface → Control → Observation → Evidence → Risk → Recommendation

Strong identity security requires multiple layers:

Strong Credentials + MFA + Limited Exposure + Secure Sessions + Monitoring + Appropriate Privileges

What’s Next?

➡️ Lab 08 — Linux Security Assessment

In the next lab, you will take an authorized Linux training system and perform a structured host-level security review.

You will investigate:

users and groups
privilege assignments
file and directory permissions
running processes
listening services
scheduled tasks
system configuration
authentication configuration
logs
sensitive-file exposure
security-control configuration

The methodology becomes:

Host → Identity → Privilege → Process → Service → Filesystem → Configuration → Logs → Security Finding

By the end of Lab 08, you should be able to answer:

“What is the security posture of this Linux host, which configurations increase its attack surface, and which findings should be remediated first?”