Authentication

Introduction to Authentication

Authentication is the process of verifying that a person, device, application
or service is really the identity it claims to be.

Whenever a user logs into a website with a username and password, presents a
security key, approves a multi-factor authentication request or uses a
passkey, an authentication process is taking place.

Authentication is one of the most important foundations of cybersecurity
because many protected resources depend on knowing who is making a request.

1. Authentication vs Authorization

Authentication and authorization are related but different security controls.

A secure application normally performs authentication before granting access
to protected functionality, but successful authentication does not
automatically mean that the user should have access to every resource.

2. Authentication Factors

Authentication factors are commonly grouped into several categories.

Knowledge Factor

Something the user knows.

• Password
• PIN
• Passphrase

Possession Factor

Something the user has.

• Security key
• Authenticator application
• Registered mobile device

Inherence Factor

Something the user is.

• Fingerprint
• Face recognition
• Other biometric characteristics

Contextual Factors

Some systems also consider contextual information such as device posture,
location patterns, network characteristics or the sensitivity of the
requested operation.

Context should normally complement stronger authentication controls rather
than being treated as a perfect identity proof.

3. Password Authentication

Passwords remain common because they are relatively easy to implement and
understand. However, passwords can be stolen, reused, guessed, exposed in
breaches or entered into fraudulent websites.

A secure password system should therefore consider:

• Strong password or passphrase creation.
• Secure password hashing.
• Rate limiting.
• Protection against automated login attempts.
• Multi-factor authentication.
• Secure password recovery.
• Protection against breached passwords.
• Secure handling of authentication logs.

Passwords should never be stored as plain text.

4. Multi-Factor Authentication

Multi-factor authentication, commonly called MFA, requires more than one
authentication factor.

For example, a system might require:

1. A password.
2. A one-time verification code from an authenticator application.

The goal is to reduce the impact of a stolen password because possession of
the password alone may no longer be enough to authenticate.

Common MFA Technologies

• Time-based one-time passwords (TOTP).
• Push authentication.
• Hardware security keys.
• Passkeys.
• Biometric verification combined with another factor.

5. TOTP Authentication

Time-based one-time passwords, or TOTP, generate short-lived verification
codes using a shared secret and the current time.

Authenticator applications commonly use this approach.

A TOTP code should normally be treated as a temporary authentication factor,
not as a permanent password.

6. Security Keys

Security keys are physical authentication devices that can use modern
cryptographic authentication standards.

They can provide stronger protection against certain forms of credential
phishing because authentication is cryptographically associated with the
legitimate website or service.

Security keys are particularly useful for administrators, developers and
other users with access to sensitive systems.

7. Passkeys

Passkeys are a modern authentication mechanism based on public-key
cryptography.

Instead of the server storing a reusable password for the user, the
authentication system uses a public/private key relationship.

The private key remains protected by the user’s device or credential
manager, while the corresponding public key can be registered with the
service.

Passkeys can provide strong resistance against many traditional
password-based attacks and can support convenient authentication across
modern devices.

8. The Authentication Lifecycle

Authentication is not limited to pressing the login button.

A complete authentication lifecycle can include:

1. Account registration.
2. Identity verification where required.
3. Credential creation.
4. Login.
5. Multi-factor verification.
6. Session establishment.
7. Reauthentication for sensitive actions.
8. Logout.
9. Password or credential recovery.
10. Account suspension or deletion.

9. Secure Registration

Registration is the point where a new identity enters the application.

A secure registration process should consider:

• Input validation.
• Duplicate account handling.
• Secure password hashing.
• Email verification where appropriate.
• MFA enrollment.
• Protection against automated account creation.
• Privacy requirements.
• Secure handling of recovery information.

10. Secure Login Flow

A typical secure login flow can be represented as:

1. User submits an identifier.
2. Server validates the request format.
3. Server retrieves the appropriate account record.
4. Password or credential verification occurs securely.
5. Additional authentication factors are checked.
6. Authentication events are recorded appropriately.
7. A secure authenticated session is established.
8. The user receives access according to their authorization level.

Authentication logic should be performed on the server. Client-side checks
can improve user experience but should never be treated as the final
security control.

11. Authentication Error Messages

Applications should avoid revealing unnecessary information through login
errors.

For example, messages such as:

Username does not exist.

may reveal whether an account is registered.

A more general message can reduce unnecessary account enumeration:

Invalid username or password.

The exact approach should consider the application’s security requirements,
usability and account recovery process.

12. Rate Limiting and Throttling

Authentication endpoints should be protected against excessive automated
requests.

Controls can include:

• Rate limiting.
• Progressive delays.
• Risk-based challenges.
• MFA.
• Monitoring of repeated failures.
• Temporary restrictions where appropriate.

Authentication controls should be designed carefully because aggressive
lockouts can themselves create usability and availability problems.

13. Credential Stuffing

Credential stuffing occurs when attackers attempt previously exposed
username/password combinations against another service.

The underlying problem is often password reuse across different websites.

Defensive controls include:

• MFA.
• Breached-password screening.
• Rate limiting.
• Bot detection.
• Monitoring unusual login patterns.
• Encouraging password managers and unique passwords.

14. Password Spraying

Password spraying is an authentication attack concept in which a small
number of commonly used passwords may be attempted against many accounts
rather than repeatedly targeting one account.

Defensive monitoring can look for patterns such as:

• Many accounts experiencing failures from related sources.
• Unusual authentication locations.
• Large numbers of failed attempts over a short period.
• Authentication attempts outside normal organizational patterns.

Students should study this concept only in authorized defensive labs.

15. Phishing-Resistant Authentication

Traditional passwords can be captured by fraudulent websites.

Some modern authentication mechanisms provide stronger protection because
they use cryptographic credentials tied to the legitimate service.

Examples include:

• Passkeys.
• FIDO-based security keys.
• Modern public-key authentication systems.

Organizations should select authentication methods based on their users,
applications, risk profile and operational requirements.

16. Reauthentication

Some actions are sensitive enough to justify asking the user to authenticate
again even when an active session already exists.

Examples include:

• Changing a password.
• Changing MFA settings.
• Changing recovery information.
• Viewing highly sensitive information.
• Changing financial information.
• Performing high-impact administrative actions.

Reauthentication reduces the risk associated with a long-lived unattended
session.

17. Authentication and Sessions

After successful authentication, a web application normally establishes a
session or another mechanism that allows subsequent requests to be associated
with the authenticated user.

Session security is covered in detail later in this module under
Session Security.

Important principles include:

• Use secure session identifiers.
• Regenerate session identifiers after authentication where appropriate.
• Protect authentication cookies.
• Expire sessions appropriately.
• Invalidate sessions during logout.

18. OAuth 2.0 and OpenID Connect

OAuth 2.0 is primarily an authorization framework that allows applications
to obtain limited access to resources without directly handling another
service’s password.

OpenID Connect builds an identity layer on top of OAuth 2.0 concepts to
support authentication and identity information.

Students should remember:

19. API Authentication

Web APIs also need authentication mechanisms.

Common approaches include:

• API keys.
• Bearer tokens.
• Signed tokens.
• OAuth access tokens.
• Service accounts.
• Mutual TLS in specialized environments.

API credentials should be protected like other sensitive secrets.
Applications should avoid exposing them in client-side source code,
public repositories or unnecessary logs.

20. Authentication Tokens

Authentication tokens represent an authenticated state or authorization
context.

Security considerations include:

• Use secure token generation.
• Use appropriate expiration periods.
• Protect tokens from unnecessary exposure.
• Revoke tokens where the architecture supports revocation.
• Avoid putting sensitive secrets into URLs unnecessarily.
• Protect browser storage appropriately.
• Never log complete sensitive tokens unnecessarily.

21. Account Recovery

Account recovery is part of authentication security.

A recovery system should not become an easier route around the main
authentication controls.

Important considerations include:

• Secure password reset tokens.
• Short-lived recovery links.
• One-time use recovery tokens.
• Appropriate identity verification.
• MFA recovery procedures.
• Recovery-code protection.
• Notification of important account changes.

22. Authentication Logging

Authentication events are valuable for security monitoring.

Useful events can include:

• Successful login.
• Failed login.
• Password change.
• MFA enrollment.
• MFA failure.
• Password reset request.
• Successful password reset.
• New device registration.
• Session termination.
• Administrative authentication changes.

Logs should avoid storing passwords, recovery secrets or complete
authentication tokens.

23. Detecting Suspicious Authentication

Organizations can use authentication logs to identify unusual patterns.

Possible indicators include:

• Repeated failed logins.
• Unexpected geographic patterns.
• New devices.
• Unusual login times.
• Rapid changes in account settings.
• Multiple authentication failures followed by a successful login.
• Unexpected privileged-account activity.

These indicators do not automatically prove compromise. They should be
investigated together with other available evidence.

24. WordPress Authentication

WordPress provides built-in user authentication and account management
features.

Developers working with WordPress should understand the difference between:

• User authentication.
• User roles.
• Capabilities.
• Nonces.
• Authentication cookies.

A nonce is not a replacement for authentication. It is a request-verification
mechanism used to help protect certain actions from unwanted requests.

Sensitive WordPress actions should also use capability checks such as
current_user_can().

25. Secure PHP Authentication Example

The following example demonstrates safe password verification using a
synthetic user record. It does not perform password guessing or credential
collection.

<?php

$user = array(
    'username' => 'student001',
    'password_hash' => password_hash(
        'Example-Strong-Passphrase-2026',
        PASSWORD_DEFAULT
    ),
);

$submitted_password = 'Example-Strong-Passphrase-2026';

if (
    password_verify(
        $submitted_password,
        $user['password_hash']
    )
) {

    echo 'Authentication successful.';

} else {

    echo 'Invalid username or password.';
}

In a real application, the password hash would already be stored in a
secure database field. The application should never store the original
password as plain text.

26. Checking Whether a Password Hash Needs Rehashing

Password libraries can provide mechanisms for determining whether an
existing password hash should be upgraded to a newer or stronger algorithm
configuration.

<?php

$password_hash = password_hash(
    'Example-Strong-Passphrase-2026',
    PASSWORD_DEFAULT
);

if ( password_needs_rehash(
    $password_hash,
    PASSWORD_DEFAULT
) ) {

    echo 'Password hash should be upgraded.';

} else {

    echo 'Password hash configuration is current.';
}

27. Authentication Security Checklist

• Use secure password hashing.
• Never store plain-text passwords.
• Use MFA where appropriate.
• Prefer phishing-resistant authentication for high-risk accounts where practical.
• Protect login endpoints from excessive automated requests.
• Use secure account recovery.
• Protect authentication sessions.
• Use secure cookies.
• Reauthenticate sensitive operations.
• Monitor authentication events.
• Protect API credentials.
• Do not expose secrets in source code.
• Do not log passwords or complete authentication tokens.
• Apply least privilege after authentication.

28. Practical Cybersecurity Lab

Create a small local authentication demonstration in your development
environment.

The exercise should contain:

1. A synthetic user account.
2. A password stored only as a secure hash.
3. A login form.
4. Server-side password verification.
5. A simulated failed-login counter.
6. A basic rate-limiting demonstration.
7. A simulated MFA verification step.
8. A security log containing successful and failed authentication events.

Use only accounts and systems that you own or have explicit permission to
test.

29. Authentication Security Scenario

Imagine that a training website reports the following events:

• Twenty failed login attempts against several accounts.
• The attempts occur within a short period.
• The usernames belong to different departments.
• One account eventually authenticates successfully.
• The successful login originates from an unusual device.

A security analyst should not immediately conclude that compromise has
occurred. Instead, the analyst should examine authentication logs,
device information, MFA events, account activity and other available
evidence.

Possible defensive actions may include:

• Confirming whether the successful user recognizes the login.
• Reviewing MFA activity.
• Checking for password-reset events.
• Reviewing session activity.
• Requiring additional verification where appropriate.
• Resetting credentials if compromise is confirmed.
• Revoking active sessions when necessary.

30. Common Authentication Mistakes

• Storing passwords in plain text.
• Using weak or outdated password hashing.
• Relying only on client-side validation.
• Using predictable authentication tokens.
• Leaving authentication endpoints unprotected from excessive requests.
• Revealing whether usernames exist through detailed error messages.
• Using insecure password-reset mechanisms.
• Logging passwords or sensitive tokens.
• Failing to protect administrator accounts with strong authentication.
• Treating authentication as the same thing as authorization.

31. Authentication and the CIA Triad

32. Key Takeaways

• Authentication verifies identity.
• Authorization determines what an authenticated identity may do.
• Passwords should be securely hashed rather than stored as plain text.
• MFA adds additional authentication factors.
• Passkeys and security keys can provide strong phishing resistance.
• Authentication includes registration, login, recovery, session establishment and logout.
• Rate limiting helps protect authentication endpoints from excessive automated attempts.
• Account recovery must be protected as carefully as normal login.
• Authentication tokens and sessions must be protected from exposure.
• OAuth 2.0 and OpenID Connect serve different but related purposes.
• Authentication logs can help detect suspicious activity.
• Authentication should always be followed by appropriate authorization checks.

33. Review Questions

1. What is authentication?
2. How is authentication different from authorization?
3. What are the major authentication factors?
4. What is multi-factor authentication?
5. What is TOTP?
6. What are security keys?
7. What are passkeys?
8. Why should passwords never be stored as plain text?
9. What is credential stuffing?
10. What is password spraying?
11. Why is rate limiting useful for authentication endpoints?
12. Why is secure account recovery important?
13. What is the difference between OAuth 2.0 and OpenID Connect?
14. Why should authentication tokens be protected?
15. Why should sensitive actions sometimes require reauthentication?

Conclusion

Authentication is a foundational cybersecurity control. Strong authentication
requires more than simply creating a login form. Developers and security
professionals must consider identity verification, password security,
multi-factor authentication, recovery, session establishment, rate limiting,
logging and secure handling of authentication tokens.

The next lesson will examine Authorization and how
applications determine what authenticated users are permitted to access or
perform.