SY0-701Chapter 6 of 212Objective 1.2

Authentication Methods

This chapter covers authentication methods — the mechanisms that verify a user's identity before granting access to systems and data. For the SY0-701 exam, this topic falls under Domain 1.0 (General Security Concepts), Objective 1.2: 'Given a scenario, analyze potential indicators to determine the type of attack.' Understanding authentication factors, protocols, and common attacks is critical for identifying vulnerabilities and implementing secure access controls. We'll explore knowledge factors (passwords), possession factors (tokens), inherence factors (biometrics), and location/time factors, along with multi-factor authentication (MFA) and single sign-on (SSO) implementations.

25 min read
Beginner
Updated May 31, 2026

The Castle Key System: Authentication Factors

Imagine a medieval castle with three layers of security. The outer gate (something you know) requires a password — a secret phrase known only to you. If you forget it, you're locked out. The inner gate (something you have) requires a physical key — a unique metal object you must possess. Even if an enemy learns the password, they cannot enter without the key. The throne room door (something you are) uses a magical seal that reads your unique fingerprint — no one else can mimic it. Now, a spy (attacker) might try to guess the password (brute force), steal the key (physical theft), or forge a fake fingerprint (biometric spoofing). To defend, the castle uses multi-factor authentication: you must present all three at once. If one factor is compromised, the others still protect. This mirrors how authentication systems combine factors to ensure only the legitimate user gains access.

How It Actually Works

What is Authentication?

Authentication is the process of verifying the identity of a user, device, or system. It answers the question: 'Who are you?' and ensures that the entity is who it claims to be. This is distinct from authorization (what you are allowed to do) and accounting (tracking actions). The three core factors are: - Something you know: Knowledge factor (e.g., password, PIN, security question). - Something you have: Possession factor (e.g., smart card, hardware token, smartphone). - Something you are: Inherence factor (e.g., fingerprint, iris scan, voice pattern).

Additional factors include: - Somewhere you are: Location factor (e.g., GPS, IP address, geofencing). - Something you do: Behavioral factor (e.g., typing rhythm, mouse movements).

How Authentication Works Mechanically

When a user attempts to log in, the system collects credentials (e.g., password, token code, biometric sample). The authentication server compares these against a stored reference (e.g., password hash, public key, biometric template). If they match, the user is granted access. The process often involves: 1. Credential capture: User enters password or scans fingerprint. 2. Transmission: Credentials sent over a secure channel (e.g., TLS/SSL) to avoid interception. 3. Verification: Server checks against stored data. For passwords, it compares the hash of the entered password against the stored hash. 4. Session creation: Server issues a session token (e.g., JSON Web Token) for subsequent requests.

Key Components and Standards

Password policies: Length (minimum 8-12 characters), complexity (uppercase, lowercase, digits, symbols), expiration (e.g., 90 days), and history (e.g., last 10 passwords).

Password hashing: Use of strong algorithms like bcrypt, PBKDF2, or Argon2 to store passwords as hashes. Do not use MD5 or SHA-1 (vulnerable to rainbow tables).

Salting: Adding a unique random value to each password before hashing to prevent rainbow table attacks.

Multi-Factor Authentication (MFA): Requires two or more factors from different categories. Example: password (know) + SMS code (have) + fingerprint (are).

Single Sign-On (SSO): Allows users to authenticate once and access multiple systems. Implemented via protocols like SAML (Security Assertion Markup Language), OAuth 2.0, and OpenID Connect.

Federated Identity: SSO across different organizations. Example: using Google credentials to log into a third-party app.

Biometric systems: Use False Acceptance Rate (FAR) and False Rejection Rate (FRR) to measure accuracy. Common types: fingerprint (capacitive/optical), facial recognition (infrared/3D), iris scan, voice recognition.

Token-based authentication: Hardware tokens (RSA SecurID) generate time-based one-time passwords (TOTP) every 30-60 seconds. Software tokens (Google Authenticator) use same algorithm.

Certificate-based authentication: Uses X.509 digital certificates issued by a Certificate Authority (CA). Common in smart cards and client TLS authentication.

How Attackers Exploit Authentication

Brute force: Automated guessing of passwords. Defended by account lockout (e.g., 3 failed attempts = 15-minute lock) and rate limiting.

Dictionary attack: Using common passwords from leaked lists. Defended by password complexity and checking against known compromised passwords.

Phishing: Tricking users into entering credentials on fake sites. Defended by MFA and user training.

Keylogging: Capturing keystrokes via malware. Defended by using virtual keyboards or hardware security keys.

Pass-the-hash: Attacker captures NTLM hash and uses it to authenticate without knowing the plaintext password. Defended by using Kerberos with smart cards.

Biometric spoofing: Using a fake fingerprint (e.g., gelatin mold) or high-res photo. Defended by liveness detection (e.g., pulse check, blink detection).

Token theft: Stealing a hardware token or intercepting SMS codes (SIM swapping). Defended by using app-based TOTP or hardware security keys (FIDO2).

Real Commands and Tools

Password cracking: John the Ripper, Hashcat. Example: john --format=bcrypt hashes.txt

Brute force prevention: fail2ban on Linux to block IPs after multiple failed SSH attempts.

Certificate generation: openssl req -new -x509 -days 365 -keyout key.pem -out cert.pem

NTLM hash extraction: mimikatz sekurlsa::logonpasswords (post-exploitation tool).

TOTP generation: oathtool --totp -b <secret_key>

Exam Relevance

SY0-701 tests the ability to identify authentication methods from scenarios. Know the difference between single-factor, multi-factor, and two-factor (2FA is a subset of MFA requiring exactly two factors). Be aware of common authentication protocols (Kerberos, NTLM, LDAP, RADIUS, TACACS+). Understand that biometrics have privacy implications and are not foolproof. Recognize that SSO introduces a single point of failure (if SSO is compromised, all systems are accessible).

Walk-Through

1

User requests access to system

The user initiates a login request by opening an application or website. The system presents a login prompt. At this stage, no credentials have been transmitted. The system may also check the client's IP address or browser fingerprint for preliminary risk assessment. For example, a banking site might flag a login from a new device or country.

2

User provides primary credential (knowledge factor)

The user enters a password or PIN. The client-side application may hash the password before transmission to avoid exposing the plaintext. The credential is sent over TLS-encrypted connection. The server receives the credential and retrieves the stored hash and salt for the username. It then hashes the entered password with the same salt and compares the result. If they match, the user passes the first factor.

3

System prompts for second factor (if MFA enabled)

If MFA is configured, the server sends a challenge to the user. For a possession factor, this could be a push notification to a registered smartphone, a TOTP code request, or a hardware key insertion. The user provides the second factor. The server verifies the TOTP by computing the expected code using the shared secret and current time window (usually 30 seconds). For biometrics, a sensor captures the fingerprint or face and sends a template to the server for matching.

4

Server validates all factors and creates session

Once all required factors are verified, the authentication server generates a session token (e.g., a signed JWT containing user ID, roles, and expiration). The token is sent to the client and stored (e.g., in a cookie or local storage). For subsequent requests, the client presents this token instead of re-authenticating. The server validates the token's signature and expiry on each request.

5

User accesses authorized resources

With a valid session token, the user can now access resources based on their authorization level. The system logs the authentication event (successful login, timestamp, IP address) in audit logs. Failed attempts are also logged for security monitoring. If the session expires or the user logs out, the token is invalidated and the user must re-authenticate.

What This Looks Like on the Job

Scenario 1: Enterprise SSO Implementation A large corporation deploys Microsoft Active Directory Federation Services (AD FS) for SSO across Office 365 and internal apps. An engineer notices that users are reporting frequent token expiration errors. Investigation reveals that the token lifetime setting is too short (15 minutes) for long-running workflows. The correct response is to adjust the token lifetime to a reasonable value (e.g., 8 hours) and implement refresh tokens. A common mistake is to disable token expiration entirely, which increases risk if a token is stolen. The engineer should also enable multi-factor authentication for all SSO logins to mitigate credential theft.

Scenario 2: Biometric Authentication Failure A SOC analyst detects multiple failed biometric login attempts from a single user account within seconds. The logs show the fingerprint scanner is returning partial matches against different users. This indicates a possible biometric spoofing attack or a sensor malfunction. The analyst should review the False Acceptance Rate (FAR) threshold — if set too high, it allows impostors. The correct response is to lower the threshold and enable liveness detection. A common mistake is to ignore the alerts assuming it's a hardware issue, allowing an attacker to gain access.

Scenario 3: Password Spray Attack An organization uses a cloud-based application without MFA. An attacker uses a list of common passwords (e.g., 'Spring2024!') and attempts them against many usernames to avoid lockout. The SIEM detects a spike in failed logins from a single IP across multiple accounts. The correct response is to block the IP, enable MFA for all users, and implement account lockout policies. A common mistake is to only reset the password for one compromised account, missing the broader attack pattern.

How SY0-701 Actually Tests This

SY0-701 Objective 1.2 requires you to 'analyze potential indicators to determine the type of attack.' Authentication-related attacks are a major focus. Specifically, you must be able to distinguish between:

Brute force vs. dictionary attacks (brute force tries all combinations; dictionary uses a list of likely passwords).

Online vs. offline attacks (online requires interaction with the server; offline uses captured hashes).

Password spraying vs. credential stuffing (spraying uses one password against many accounts; stuffing uses known credentials from breaches).

Common Wrong Answers: 1. 'Biometrics are unspoofable' — many candidates believe this, but biometrics can be spoofed with molds or high-resolution images. The correct answer is that liveness detection mitigates this. 2. 'MFA always prevents phishing' — MFA reduces risk but can be bypassed via real-time phishing (e.g., evilginx) that captures both password and OTP. 3. 'SSO increases security' — SSO is convenient but introduces a single point of failure; if the SSO provider is compromised, all federated apps are at risk.

Key Terms to Memorize: - TOTP (Time-based One-Time Password) - HOTP (HMAC-based One-Time Password) - FIDO2/WebAuthn (passwordless authentication using public-key cryptography) - RADIUS (Remote Authentication Dial-In User Service) — port 1812/1813 - TACACS+ (Terminal Access Controller Access-Control System Plus) — port 49 - LDAP (Lightweight Directory Access Protocol) — port 389/636 - Kerberos — port 88

Trick Questions: - 'What factor is a smart card?' It is 'something you have' (possession factor), but the PIN used to unlock it is 'something you know.' The card alone is not MFA; the combination is 2FA. - 'Is a fingerprint alone considered MFA?' No, it is single-factor (inherence). MFA requires factors from different categories.

Decision Rule: When a scenario describes an attack on authentication, first identify the factor being targeted. If the attacker is guessing passwords, it's a knowledge factor attack. If they steal a token, it's possession. If they spoof a biometric, it's inherence. Then match the attack name (e.g., brute force, phishing, pass-the-hash) to the indicator.

Key Takeaways

Authentication factors: knowledge (password), possession (token), inherence (biometric), location (IP), behavior (typing pattern).

MFA requires at least two different factors; 2FA requires exactly two.

Password hashing should use bcrypt, PBKDF2, or Argon2; never MD5 or SHA-1.

Biometric systems have FAR (False Acceptance Rate) and FRR (False Rejection Rate); lower FAR is more secure but may increase FRR.

TOTP uses time-based codes (30-60 second window); HOTP uses event-based counter.

Kerberos uses tickets and symmetric keys; default port 88.

RADIUS (port 1812/1813) combines authentication and authorization; TACACS+ (port 49) separates them.

SSO protocols: SAML (XML), OAuth 2.0 (JSON), OpenID Connect (authentication on top of OAuth 2.0).

Common attacks: brute force, dictionary, password spray, credential stuffing, pass-the-hash, phishing, token theft, biometric spoofing.

Defenses: account lockout, rate limiting, MFA, liveness detection, certificate-based authentication, FIDO2 security keys.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

SAML (Security Assertion Markup Language)

XML-based protocol for SSO

Primarily used for enterprise SSO (e.g., AD FS)

Relies on assertions (authentication and attribute statements)

Uses HTTP POST or Redirect bindings

Not designed for API authorization

OAuth 2.0 / OpenID Connect

JSON-based (RESTful) protocol

Commonly used for social login and API access (e.g., Google, Facebook)

Uses access tokens and ID tokens (JWT)

OAuth 2.0 is for authorization; OpenID Connect adds authentication layer

Designed for mobile and web APIs

Watch Out for These

Mistake

Two-factor authentication (2FA) and multi-factor authentication (MFA) are the same thing.

Correct

2FA is a subset of MFA that requires exactly two factors. MFA can require two or more factors. All 2FA is MFA, but not all MFA is 2FA (e.g., three factors is MFA but not 2FA).

Mistake

Biometric authentication is 100% secure because everyone's biometrics are unique.

Correct

Biometrics can be spoofed (e.g., fake fingerprints, silicone masks) and have false acceptance rates. They are also not revocable if compromised (you can't change your fingerprint).

Mistake

A strong password alone is sufficient for security.

Correct

Even strong passwords can be stolen via phishing, keyloggers, or database breaches. MFA adds a second layer of protection.

Mistake

Single sign-on (SSO) always reduces security risk.

Correct

SSO reduces password fatigue and phishing risk, but creates a single point of failure. If the SSO provider is compromised, all connected services are accessible.

Mistake

Security questions are a secure form of authentication.

Correct

Security questions (e.g., 'What is your mother's maiden name?') are often guessable or discoverable via social media, making them weak. They should be avoided or used only as a secondary factor.

Frequently Asked Questions

What is the difference between authentication and authorization?

Authentication verifies identity (who you are), while authorization determines what you are allowed to do (access rights). For example, logging in with a password is authentication; being granted read/write access to a file is authorization. On the exam, always identify which step is being described: if it's about proving identity, it's authentication; if it's about permissions, it's authorization.

What is the most secure authentication factor?

There is no single 'most secure' factor; security depends on implementation and context. However, hardware-based possession factors like FIDO2 security keys are highly resistant to phishing and remote attacks because they use public-key cryptography and never reveal the private key. Biometrics are convenient but can be spoofed. Passwords are weakest due to human error. The best approach is MFA combining multiple factors.

How does pass-the-hash attack work?

A pass-the-hash attack exploits the NTLM authentication protocol. An attacker captures the NTLM hash of a user's password (e.g., via Mimikatz on a compromised machine). Instead of cracking the hash, the attacker uses it directly to authenticate to other systems that accept NTLM hashes. This bypasses the need for the plaintext password. Defenses include using Kerberos (which uses tickets), restricting local admin rights, and enabling Credential Guard in Windows.

What is the difference between TOTP and HOTP?

TOTP (Time-based One-Time Password) generates codes based on the current time and a shared secret. Codes expire after a short window (usually 30 seconds). HOTP (HMAC-based One-Time Password) uses a counter that increments with each successful authentication. TOTP is more common because it doesn't require synchronization of a counter, but both are used in hardware and software tokens. On the exam, remember that TOTP is time-based, HOTP is counter-based.

Can biometrics be used as a single factor for MFA?

No. Biometrics are a single factor (inherence). For MFA, you need at least two different factors. For example, fingerprint + password (something you are + something you know) qualifies as MFA. Using only fingerprint is single-factor authentication. On the exam, if a scenario says 'user authenticates with fingerprint only,' that is not MFA.

What is the role of a Certificate Authority in authentication?

A Certificate Authority (CA) issues digital certificates that bind a public key to an identity (e.g., user or device). During certificate-based authentication, the user presents their certificate, and the system verifies it against the CA's trust chain. This ensures the public key belongs to the claimed identity. Certificates are commonly used in smart cards, client TLS, and VPN authentication.

How does OAuth 2.0 differ from OpenID Connect?

OAuth 2.0 is an authorization framework that allows a third-party app to obtain limited access to a user's resources (e.g., read email) without sharing credentials. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. OIDC adds an ID token (JWT) that contains user identity information, allowing the app to verify the user's identity. OAuth 2.0 alone does not authenticate the user; OIDC does.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Authentication Methods — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.

Done with this chapter?