Authentication Factors, MFA, and Passwordless Identity

Introduction

Authentication is the process of establishing that a claimant is the legitimate user, device, service, or system associated with an identity. Authorization follows authentication: it determines what the authenticated subject may access or do. The quality of authorization decisions therefore depends partly on the reliability of authentication evidence.

Modern applications rarely rely on a single password alone. Passwords are reusable secrets, frequently shared across services, vulnerable to phishing, and exposed through breaches. Contemporary identity design combines multiple authentication factors, phishing-resistant authenticators, adaptive risk assessment, and carefully planned recovery procedures. The objective is not simply to make login harder. It is to obtain an appropriate level of assurance while preserving usability, accessibility, privacy, availability, and recoverability.

This chapter examines the major authentication factors, multi-factor authentication (MFA), one-time passwords, biometrics, smart cards, FIDO2, WebAuthn, and passkeys. It also considers assurance, threat resistance, lifecycle management, and the governance issues that arise when authentication becomes part of a large software ecosystem.

Learning Objectives

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

1. Distinguish knowledge, possession, inherence, contextual, and behavioral authentication factors.
2. Explain why two authentication methods from the same category do not necessarily constitute MFA.
3. Select authentication mechanisms according to risk, usability, accessibility, and assurance requirements.
4. Design TOTP, smart-card, FIDO2, WebAuthn, and passkey-based authentication flows.
5. Compare OTP and phishing-resistant authenticators.
6. Design enrollment, recovery, revocation, and incident-response controls.
7. Evaluate ethical, privacy, regulatory, and operational implications of authentication systems.

1. Authentication Factors and Assurance

1.1 The factor categories

An authentication factor is a class of evidence used to support an identity claim. The principal categories are shown below.

The first three categories are traditionally called authentication factors. Contextual and behavioral evidence are often treated as risk signals or supplementary factors rather than independent primary factors. Their classification depends on the assurance framework and implementation. A device location, for example, is not necessarily controlled by the user and may be falsified; it should rarely be the sole basis for a high-impact decision.

1.2 Authentication is not identification or authorization

Identification is the assertion of an identity, such as entering an email address. Authentication tests that assertion. Authorization evaluates permissions after authentication. Accounting and auditing record relevant actions. Confusing these functions causes design errors: a username is not proof of identity, and successful authentication does not imply permission to access every resource.

1.3 Assurance and threat resistance

Authentication assurance concerns the confidence that an authenticator is controlled by the intended subject and that the protocol resists relevant attacks. Assurance is not identical to convenience or the number of login steps. A complex password can provide less practical protection than a simple phishing-resistant security key.

A design should begin with a threat model. Relevant threats include:

• online guessing and credential stuffing;
• phishing and adversary-in-the-middle attacks;
• malware on endpoints;
• theft or loss of devices;
• SIM-swap and telecommunications compromise;
• insider misuse;
• database compromise;
• denial of service and account lockout;
• coercion and unauthorized recovery.

The required authentication strength should be proportional to the consequences of compromise. A public discussion forum, payroll system, clinical record system, and cloud administrator account should not necessarily use identical controls.

2. Knowledge, Possession, Inherence, Context, and Behavior

2.1 Knowledge factors

Passwords and PINs are inexpensive and widely interoperable. Secure password storage requires a password-derived verifier rather than plaintext. A server should use a modern password hashing or password-based key derivation function with a unique salt and an appropriate work factor. Encryption alone is not a substitute: if the decryption key is compromised, all stored passwords may be exposed.

Password policies should discourage common and compromised passwords, support password managers, permit adequate length, and avoid arbitrary composition rules that encourage predictable transformations. Rate limiting, breached-password screening, secure reset procedures, and phishing-resistant alternatives are more useful than requiring frequent routine changes without evidence of compromise.

A PIN protecting a local authenticator is usually a knowledge factor, while the authenticator itself is a possession factor. The combination can therefore provide two factors when the PIN and device are independently controlled.

2.2 Possession factors

A possession factor is based on control of a physical or logically protected object. Examples include hardware security keys, smart cards, mobile authenticator applications, and dedicated OTP tokens. Possession is not proven merely because a message was sent to a telephone number; the channel and device may be compromised.

Possession systems require lifecycle controls: secure enrollment, replacement, inventory, revocation, loss reporting, and recovery. A system that enrolls an authenticator weakly may provide strong login cryptography but weak overall assurance.

2.3 Inherence factors and biometrics

Biometrics use physiological or biological characteristics. They are valuable for unlocking a device or local credential, but they have special limitations. A fingerprint cannot normally be changed after disclosure, and biometric measurements are probabilistic rather than exact. Systems must manage false acceptance and false rejection.

Let FAR denote the false-acceptance rate: the probability that an unauthorized sample is accepted. Let FRR denote the false-rejection rate: the probability that an authorized sample is rejected. Changing the matching threshold commonly creates a trade-off: a stricter threshold can reduce FAR but increase FRR. These rates depend on the sensor, population, environment, algorithm, and operating point; they should not be treated as universal constants.

Biometric systems should generally keep biometric templates on a user-controlled device where possible. In a passkey design, a fingerprint or face scan often unlocks a private key locally; the service receives a cryptographic assertion, not the biometric image. This arrangement reduces central biometric exposure but does not eliminate privacy or accessibility concerns.

Biometrics should not be the only recovery route. Users may have injuries, disabilities, aging-related changes, cultural concerns, or environmental conditions that affect recognition. Alternative authenticators must be available without automatically reducing security to an easily attacked channel.

2.4 Contextual and behavioral signals

Contextual signals include IP reputation, device health, location, time, and network. Behavioral signals include typing cadence, navigation patterns, and transaction behavior. These signals are useful for adaptive authentication, such as requiring a security key for an unusual administrator login.

They are probabilistic evidence, not infallible identity proof. A legitimate traveler may appear anomalous, while an attacker may operate from a familiar network. Risk engines should use transparent policies, calibrated thresholds, human review for high-impact decisions, and an appeal path. Behavioral monitoring also raises concerns about surveillance, discrimination, data retention, and secondary use.

3. Multi-Factor Authentication

MFA requires evidence from at least two distinct factor categories. A password plus a TOTP code is knowledge plus possession. A smart card plus its PIN is possession plus knowledge. A password plus a second password is still one factor category, even if the passwords differ.

MFA should be analyzed as a system rather than a checklist. Important design questions include:

1. Which threats must be resisted?
2. Are the factors independent enough that one compromise does not defeat both?
3. Is the protocol resistant to phishing and replay?
4. What happens when an authenticator is lost?
5. Can an attacker enroll a new authenticator through account recovery?
6. Are high-risk operations reauthenticated or transaction-bound?

3.1 Step-up and adaptive authentication

A service can use progressive assurance. Low-risk activity may require a passkey or password, while changing payment details or exporting sensitive data triggers a stronger authenticator. This is known as step-up authentication. Adaptive authentication uses contextual signals to decide when additional evidence is required.

Adaptive decisions should be explainable enough for support and governance. A user should not be permanently blocked because of an opaque risk score. Logging should capture the policy decision, authenticator type, result, and relevant administrative action while minimizing unnecessary personal data.

3.2 Common MFA weaknesses

MFA can be undermined by:

• accepting codes through a phishing proxy;
• repeated push notifications that encourage approval fatigue;
• insecure SMS delivery and SIM substitution;
• weak help-desk identity verification;
• recovery links that bypass stronger authenticators;
• allowing an attacker to register an authenticator after stealing a session;
• failing to revoke lost or compromised devices.

Number matching, transaction details, rate limits, user education, and phishing-resistant protocols reduce some of these risks. SMS may be an accessibility or fallback option, but it should not be preferred for high-risk applications when stronger methods are practical.

4. One-Time Passwords

4.1 HOTP and TOTP

HMAC-based One-Time Password (HOTP) uses a shared secret and a counter. Time-based One-Time Password (TOTP) derives a code from a shared secret and a time step. In simplified form, TOTP computes an HMAC over a time counter and truncates the result to a short decimal code. The exact algorithm, truncation rules, digit length, time step, and validation window must follow the applicable standard rather than being improvised.

For a time step of 30 seconds, the counter can be represented as:

Here, t is the current Unix time in seconds, t₀ is the configured epoch, X is the time-step length in seconds, and T is the integer time counter. This equation only defines the counter; the OTP also requires the shared secret, HMAC function, dynamic truncation, and decimal formatting.

The server must protect the shared secret, permit only a small clock-skew window, prevent code reuse, rate-limit attempts, and provide secure enrollment. TOTP is stronger than a password alone but remains phishable: a user can enter a valid code into an attacker-controlled site, which can relay it immediately.

4.2 SMS and email codes

SMS and email codes are out-of-band or possession-related mechanisms, but their security depends on the telecommunications or email account. Number portability, SIM swaps, mailbox compromise, forwarding rules, and malware can defeat them. They may be appropriate as transitional or recovery mechanisms under controlled risk, but they are not equivalent to phishing-resistant public-key authentication.

5. Smart Cards and Certificate-Based Authentication

A smart card stores a private key in a tamper-resistant chip. During authentication, the service sends a challenge; the card signs it with the private key, often after the user enters a PIN. The service verifies the signature using a certificate and a trusted certificate authority (CA).

A typical enterprise process includes:

1. identity proofing and card issuance;
2. certificate generation and key protection;
3. CA trust configuration;
4. challenge-response authentication;
5. certificate expiry, renewal, suspension, and revocation;
6. card return or destruction when employment ends.

Smart cards can provide strong possession and knowledge factors, but they require readers, middleware, certificate management, and support. Certificate revocation must be timely and reliable. If a card is lost, the organization must revoke its credentials rather than merely disable a username.

6. FIDO2, WebAuthn, and Passkeys

6.1 Public-key authentication

FIDO2 replaces a shared server-side secret with public-key cryptography. During registration, an authenticator creates a key pair. The private key remains in the authenticator; the service stores the public key and metadata. During login, the service sends a challenge, and the authenticator signs it after verifying user presence or user verification.

The service verifies the signature using the registered public key. A database breach therefore does not reveal a reusable password or shared OTP secret. Proper implementation also binds the credential to the relying party, helping prevent phishing through origin or domain mismatch.

6.2 WebAuthn

WebAuthn is a browser and platform API for registering and using public-key credentials with a relying party. A registration request includes a challenge, relying-party identifier, user information, and authenticator-selection requirements. The returned credential contains a credential identifier and attestation-related data. At authentication, the server supplies a fresh challenge and verifies the assertion, origin, relying-party identifier hash, signature, and sign counter where applicable.

Challenges must be unpredictable, single-use, associated with the login transaction, and expire quickly. Servers must not accept an assertion for the wrong origin or relying party. They must also validate ceremony state and protect against cross-site request forgery and session fixation.

6.3 FIDO2 authenticators and user verification

A FIDO2 authenticator may be a roaming hardware key or a platform authenticator integrated into a phone or computer. User presence can involve touching a key; user verification may involve a PIN or local biometric. The biometric generally unlocks the authenticator locally rather than being sent to the service.

Attestation can provide information about an authenticator model, but mandatory device identification may reduce privacy and interoperability. Organizations should request attestation only when its security or regulatory purpose is clear.

6.4 Passkeys

A passkey is a user-facing credential based on public-key authentication, commonly using WebAuthn. A device-bound passkey remains on one device or security key. A synchronized passkey is securely replicated through a platform ecosystem so that a user can access it on multiple devices. Synchronization improves recovery and usability but introduces dependence on the provider account and synchronization security.

Passkeys are resistant to ordinary phishing because the credential is scoped to the relying party and the private key is not typed into a website. They do not eliminate every risk: malware, compromised endpoints, malicious account recovery, session theft, and social engineering remain relevant.

7. Designing an Authentication Architecture

A robust design separates the authentication ceremony from authorization policy and from recovery operations.

Enrollment

Enrollment should establish the user identity at an assurance level appropriate to the account. It should require verified contact channels or organizational identity proofing, notify the user of new authenticators, and record device metadata with restraint. For high-value accounts, require two independent authenticators during enrollment so that loss of one does not force insecure recovery.

Login

Use a fresh challenge, secure transport, anti-automation controls, session protection, and clear user-visible origin information. Prefer passkeys or hardware security keys for administrators, financial actions, and sensitive data. Passwords may remain as a fallback, but their exposure should be minimized.

Recovery

Recovery is part of authentication, not an afterthought. It should not be weaker than the normal login path. Suitable controls include previously enrolled recovery keys, verified organizational processes, delayed changes, independent notifications, support-agent approval, and transaction limits. Recovery codes should be high-entropy, single-use, stored securely, and regenerated after use.

Revocation and incident response

Provide self-service revocation where safe, rapid administrative revocation for compromised credentials, and logs of enrollment, use, recovery, and revocation. When an authenticator is lost, revoke it promptly and verify that active sessions and refresh tokens are also handled according to policy.

8. Worked Design Example

A university cloud platform serves students, faculty, and system administrators. Students access coursework and grades; faculty manage assessment data; administrators control identity and financial integrations.

For students, the design uses a passkey as the preferred authenticator and a recovery code stored offline. A password and TOTP are available during migration, but SMS is restricted to low-risk account recovery with additional verification. For faculty, require a passkey or hardware key for administrative functions and step-up authentication before exporting grades. For administrators, require two registered phishing-resistant authenticators, such as two security keys or a platform passkey plus a hardware key. Recovery requires an identity-verified service-desk process, a second administrator, a waiting period, and notification to security staff.

The system stores public keys rather than biometric data or passkey private keys. It records authenticator registration, successful and failed ceremonies, recovery events, and policy changes. It detects impossible travel and unfamiliar devices as risk signals, but it does not automatically deny access solely on location. Sessions receive appropriate expiry and reauthentication requirements based on sensitivity.

This architecture aligns assurance with impact. It also recognizes that availability matters: users can authenticate if a phone is lost, while administrators cannot silently bypass strong controls through a weak help-desk process.

9. Illustrative Case Study: Northbridge Health Services

Background

Northbridge Health Services operates a web application containing clinical scheduling and patient information. Its legacy environment uses passwords and SMS codes. Staff report frequent phishing attempts, and the security team observes repeated password-reset requests.

Problem

SMS codes are vulnerable to social engineering and SIM attacks. Password reuse creates credential-stuffing exposure. The organization must improve phishing resistance without excluding staff who use assistive technologies or work in areas with unreliable mobile connectivity.

Analysis

The most sensitive roles are clinicians, records staff, and administrators. The organization identifies three risk classes: viewing ordinary schedules, viewing clinical records, and changing or exporting records. It decides that location and typing behavior may support risk detection but cannot independently authorize access.

Approach and solution

Northbridge deploys WebAuthn passkeys as the preferred method. Platform passkeys support accessible biometric or PIN-based local verification, while hardware security keys support staff who work across shared or specialized devices. Each employee registers two authenticators. TOTP is retained temporarily for migration, with clear warnings that it is not phishing-resistant. SMS is removed from routine login and retained only under a supervised recovery process.

The recovery process requires identity verification through the employment system, approval by a designated supervisor, a delay for high-risk accounts, and notifications to the employee and security team. Exporting clinical data requires recent user verification and an authorization check independent of authentication. Logs exclude biometric samples and unnecessary personal information.

Outcome

Phishing resistance improves because the passkey is bound to the legitimate relying party. Device loss is manageable because a second authenticator is registered. Accessibility improves through multiple authenticator types and non-biometric options. The organization still maintains incident response for compromised sessions and malicious recovery attempts.

Learning points

The case demonstrates that technology selection alone is insufficient. Strong authentication depends on enrollment, origin validation, recovery, authorization separation, accessibility, monitoring, and governance.

10. Limitations, Ethics, and Governance

Authentication systems can create exclusion. A requirement for a particular smartphone, fingerprint, or network may disadvantage users with disabilities, limited connectivity, older devices, or legitimate privacy concerns. Provide equivalent alternatives and test them with representative users.

Biometric processing can reveal sensitive personal information and create risks of surveillance or function creep. Collect the minimum data necessary, prefer local matching, protect templates, define retention periods, and conduct privacy and impact assessments where required. Behavioral analytics should be proportionate and subject to access controls and review.

Organizations should align controls with applicable privacy, cybersecurity, accessibility, employment, and sector-specific requirements. Standards and guidance from recognized bodies such as NIST, FIDO Alliance, and relevant national regulators provide useful frameworks, but implementation must reflect local law and risk.

Artificial intelligence can assist anomaly detection and fraud analysis, but it should not be treated as an unquestionable identity oracle. Models may encode demographic or accessibility bias, drift over time, or generate false positives. High-impact denial decisions require human oversight, explainable procedures, data minimization, and an appeal mechanism.

Best-Practice Checklist

• Prefer phishing-resistant public-key authentication for high-risk accounts.
• Use at least two independent authenticators for privileged users.
• Treat recovery as a high-assurance authentication process.
• Store password verifiers securely and never plaintext passwords.
• Protect TOTP secrets and prevent code replay.
• Validate WebAuthn challenges, origin, relying-party identifier, and ceremony state.
• Provide accessible alternatives to biometrics and smartphones.
• Notify users about enrollment, recovery, and authenticator changes.
• Revoke lost or compromised authenticators promptly.
• Separate authentication from authorization and transaction approval.
• Minimize biometric and behavioral data collection.
• Test the complete lifecycle, including failure and recovery, not only successful login.

Chapter Summary

Authentication establishes confidence in an identity claim; authorization determines permitted actions. Knowledge, possession, inherence, contextual, and behavioral evidence have different strengths and failure modes. MFA requires distinct factor categories, but not all MFA is equally resistant to phishing. Passwords and TOTP remain useful transitional mechanisms, whereas FIDO2, WebAuthn, and passkeys use public-key cryptography and bind authentication to the legitimate relying party. Smart cards provide certificate-based possession and can be strengthened with PIN verification.

Effective authentication design includes threat modeling, assurance selection, secure enrollment, fresh challenges, origin validation, recovery, revocation, session protection, accessibility, privacy, and governance. Passkeys reduce reusable-secret and phishing risks but do not remove endpoint compromise, session theft, or recovery attacks. The strongest practical architecture matches controls to consequences and treats the entire credential lifecycle as a security boundary.

Key Terms

Authentication: Process of verifying an identity claim.

Authorization: Decision about what an authenticated subject may access or do.

Authentication factor: Category of evidence used to support identity verification.

Knowledge factor: Evidence based on something the user knows.

Possession factor: Evidence based on control of a device or object.

Inherence factor: Evidence based on a bodily characteristic.

Contextual factor: Environmental or situational evidence used in risk assessment.

Behavioral factor: Evidence based on patterns of user activity.

MFA: Authentication requiring evidence from at least two factor categories.

TOTP: Time-based one-time password generated from a shared secret and time counter.

HOTP: Counter-based HMAC one-time password.

Biometric template: Processed representation used for biometric comparison.

FIDO2: Public-key authentication ecosystem including WebAuthn and authenticator protocols.

WebAuthn: Web API for registering and using public-key credentials.

Passkey: User-facing public-key credential commonly implemented through WebAuthn.

Relying party: Service that registers and verifies an authenticator credential.

Challenge: Fresh server-generated value signed during authentication.

Attestation: Information about an authenticator supplied during registration.

Recovery: Process for regaining account access or replacing authenticators.

Phishing resistance: Ability to prevent an attacker from successfully reusing authentication evidence obtained through a fraudulent site.

Review Questions

Short Answer Questions

1. Why does a password plus a second password not normally constitute MFA?
2. Distinguish authentication from authorization.
3. State one important weakness of TOTP.
4. What is the role of a WebAuthn challenge?
5. Why should an organization register more than one authenticator for a privileged user?

Long Answer Questions

1. Compare knowledge, possession, inherence, contextual, and behavioral factors, including strengths and weaknesses.
2. Explain how passkeys use public-key cryptography to reduce phishing and database-compromise risks.
3. Design an enrollment, recovery, and revocation lifecycle for a university administrator account.
4. Compare TOTP, SMS codes, smart cards, and FIDO2 authenticators for a healthcare application.
5. Discuss the privacy, accessibility, and governance issues associated with biometric and behavioral authentication.

Analytical / Application Questions

1. A company requires passwords and push approvals, but employees approve repeated prompts without checking them. Analyze the weaknesses and propose a stronger design.
2. Design an authentication policy for students, faculty, and cloud administrators in a university. Justify different assurance levels and recovery controls.
3. A user loses a phone containing a synchronized passkey and recovery application. Develop an incident-response and account-recovery procedure that preserves security and availability.

Multiple Choice Questions with Answers

Question 1

Which combination represents two distinct authentication factors?

A. Password and security question

B. Password and TOTP code

C. Two different passwords

D. Username and password

Correct Answer: B. Password and TOTP code

Question 2

What is the principal security advantage of FIDO2 over a shared password?

A. It eliminates the need for user verification

B. It stores the private key on the application server

C. It uses a registered public-key pair instead of a reusable shared secret

D. It guarantees that endpoints cannot be infected

Correct Answer: C. It uses a registered public-key pair instead of a reusable shared secret

Question 3

Which statement about TOTP is correct?

A. It is inherently resistant to phishing

B. It derives a short-lived code using a shared secret and time counter

C. It requires a smart-card certificate

D. It never depends on clock synchronization

Correct Answer: B. It derives a short-lived code using a shared secret and time counter

Question 4

In WebAuthn, what should a server verify when processing an assertion?

A. Only the username

B. The assertion origin, relying-party binding, challenge, and signature

C. The user’s biometric image

D. The IP address as the sole identity proof

Correct Answer: B. The assertion origin, relying-party binding, challenge, and signature

Question 5

A fingerprint used to unlock a private key stored on a phone is best understood as:

A. A local user-verification method protecting a possession-based authenticator

B. A server-side password replacement stored as plaintext

C. A contextual factor based on network location

D. An authorization decision

Correct Answer: A. A local user-verification method protecting a possession-based authenticator

Question 6

Why is recovery a critical part of authentication security?

A. Recovery always has lower risk than normal login

B. Attackers may exploit weak recovery to bypass strong login controls

C. Recovery eliminates the need for revocation

D. Recovery makes authorization unnecessary

Correct Answer: B. Attackers may exploit weak recovery to bypass strong login controls

Question 7

Which is a likely weakness of SMS-based authentication?

A. It cannot transmit numerical information

B. It is always bound cryptographically to the legitimate website

C. It may be undermined by SIM swapping or telecommunications compromise

D. It requires a public-key certificate authority

Correct Answer: C. It may be undermined by SIM swapping or telecommunications compromise

Question 8

What does a false-rejection rate describe in biometric authentication?

A. The probability that an unauthorized person is accepted

B. The probability that an authorized person is rejected

C. The percentage of passwords reused by users

D. The probability that a security key is lost

Correct Answer: B. The probability that an authorized person is rejected

Question 9

Which control is most appropriate for a privileged administrator account?

A. Password-only login with unlimited attempts

B. SMS-only authentication

C. Two registered phishing-resistant authenticators and controlled recovery

D. Location-based access without authentication

Correct Answer: C. Two registered phishing-resistant authenticators and controlled recovery

Question 10

What is the primary purpose of a fresh authentication challenge?

A. To make passwords longer

B. To prevent replay of an old authentication response

C. To store biometric templates centrally

D. To replace authorization policy

Correct Answer: B. To prevent replay of an old authentication response