LFCA 96 🐧 Multi-Factor Authentication - KandZ

A password is a single factor. It is something you know. If an attacker learns it — through phishing, credential stuffing, or a data breach — they have everything they need to log in. Multi-factor authentication (MFA) changes the equation. It requires two or more different types of proof before granting access. A stolen password is no longer enough. The attacker must also possess something you have or be something you are.

The LFCA exam places MFA under Security Fundamentals, which carries 14–16% of the total weight . The competency list includes “Security,” “Sensitive Data,” and “Compliance” . MFA is the practical implementation of the authentication concept covered in earlier chapters. It is also one of the most effective security controls available: Microsoft reports that MFA can prevent over 99% of account compromise attempts .

Key point: MFA is not just “two passwords.” It requires two or more different authentication factors. Using two passwords is two-step verification, not MFA . True MFA combines something you know with something you have, something you are, or both. The distinction matters because two passwords can both be compromised by the same attack, while a password and a hardware key cannot.

Why MFA matters

Passwords are weak. They are reused across services, guessed by automated tools, phished through fake login pages, and leaked in data breaches. MFA is the layer that catches the attacker after the password has already failed.

The credential stuffing problem. An attacker obtains a list of usernames and passwords from one breached service. They try the same credentials on other services, hoping the user reused them. MFA stops this attack because the stolen password is only one factor. The attacker does not have the second factor .

The phishing problem. An attacker creates a fake login page that looks identical to the real one. The user enters their username and password. The attacker captures them. With MFA, the attacker still needs the second factor. If the second factor is a hardware security key, even a sophisticated phishing page cannot capture it, because the key cryptographically verifies the real site’s origin .

The compliance problem. Many regulatory frameworks and industry standards require MFA for access to sensitive data and administrative accounts. The NCSC-NZ MFA standard requires MFA for privileged users and business-critical systems . Microsoft now requires MFA for all Azure sign-ins .

The trade-off. MFA adds friction to the login process. Users must have their second factor available. If the factor is lost or broken, the user is locked out. The friction is real, but the alternative — a compromised account — is worse. Modern approaches reduce the friction by only prompting for MFA when necessary, using device trust as an implicit factor .

a. The Three Authentication Factors

MFA is built on three categories of authentication factors, defined by NIST’s Digital Identity Guidelines .

Something you know. A password, a PIN, a passphrase, or a security question answer. This is the knowledge factor. It is the weakest factor on its own because it can be guessed, phished, or leaked. It is also the factor that users are most accustomed to providing .

Something you have. A hardware security key, a smartphone with an authenticator app, a smart card, or a one-time password (OTP) token. This is the possession factor. The attacker must physically obtain the object to use it. This makes it significantly stronger than a password .

Something you are. A fingerprint, a facial scan, a retina scan, or a voice pattern. This is the inherence factor. Biometrics are unique to the individual and cannot be forgotten or misplaced. However, they cannot be changed if compromised, and they raise privacy concerns .

Factor	Category	Examples
Something you know	Knowledge	Password, PIN, passphrase
Something you have	Possession	Security key, authenticator app, SMS code
Something you are	Inherence	Fingerprint, face scan, iris scan

True MFA requires at least two factors from different categories. A password plus a PIN is two-step verification, not MFA, because both are knowledge factors. A password plus a fingerprint is MFA .

b. MFA Methods and Their Strength

Not all MFA methods are equally strong. The NCSC and other security agencies rank them by resistance to attack .

SMS and voice codes. A one-time code is sent to the user’s phone via text message or voice call. This is the weakest form of MFA. It is vulnerable to SIM-swapping attacks, where an attacker convinces the mobile carrier to transfer the victim’s number to a SIM card the attacker controls. It is also vulnerable to phishing, where the attacker tricks the user into revealing the code .

Authenticator apps. A mobile application generates a time-based one-time password (TOTP) every 30 seconds. The user enters the code during login. This is stronger than SMS because the code is generated locally and does not traverse the mobile network. Google Authenticator, Microsoft Authenticator, and Authy are common examples .

Push notifications with number matching. The user receives a push notification on their phone and must enter a number displayed on the login screen. This defends against MFA fatigue attacks, where an attacker bombards the user with push notifications until they accidentally approve one .

Hardware security keys (FIDO2/WebAuthn). A physical USB or NFC key that cryptographically verifies the user’s identity to the legitimate website. This is the gold standard of MFA. It is phishing-resistant because the key will not respond to a fake site. YubiKeys are a common example .

Passkeys. A passkey replaces the password entirely. It uses the FIDO2 standard and is stored on the user’s device or in a password manager. The user authenticates with biometrics or a PIN to unlock the passkey. Passkeys are phishing-resistant and eliminate the password from the equation .

Method	Strength	Vulnerabilities
SMS/Voice	Weakest	SIM swap, phishing
Authenticator app	Moderate	Phishing, code interception
Push + number matching	Strong	MFA fatigue (mitigated)
Hardware key (FIDO2)	Strongest	Physical loss
Passkeys	Strongest	Device loss

c. MFA in Linux: Protecting SSH with Google Authenticator

Linux systems can enforce MFA for SSH logins using PAM (Pluggable Authentication Modules). The pam_google_authenticator module adds a TOTP second factor to the standard password authentication .

The setup involves three steps. First, install the Google Authenticator PAM module:

sudo apt install libpam-google-authenticator

Second, generate a TOTP secret for each user:

google-authenticator

The command displays a QR code and a secret key. The user scans the QR code with an authenticator app. The secret is stored in ~/.google_authenticator .

Third, configure PAM and SSH to require the TOTP. Add the following line to /etc/pam.d/sshd:

auth required pam_google_authenticator.so

And enable challenge-response authentication in /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes

After restarting SSH (sudo systemctl restart sshd), the server prompts for the password and then the TOTP code. The user must provide both to log in .

The same PAM module can protect other services: sudo, su, and any application that uses PAM for authentication.

Complete Example Session

This session demonstrates MFA configuration on a Linux server.

# ============================================
# PART 1: INSTALL THE GOOGLE AUTHENTICATOR PAM MODULE
# ============================================

sudo apt install libpam-google-authenticator -y

# The package installs the PAM module and the google-authenticator binary.

# ============================================
# PART 2: GENERATE THE TOTP SECRET
# ============================================

google-authenticator

# Output:
# Do you want authentication tokens to be time-based (y/n) y
# ...
# Your new secret key is: ABCDEFGHIJKLMNOP
# Your verification code is: 123456
# Your emergency scratch codes are:
#   11111111
#   22222222
#   33333333
#   44444444
#   55555555
# ...
# Do you want me to update your "/home/user/.google_authenticator" file? (y/n) y
# ...
# Do you want to disallow multiple uses of the same authentication
# token? (y/n) y
# ...
# Do you want to enable rate-limiting? (y/n) y

# The QR code is displayed in the terminal.
# Scan it with the Google Authenticator app.
# The secret is stored in ~/.google_authenticator.
# The scratch codes are one-time backup codes.

# ============================================
# PART 3: CONFIGURE PAM
# ============================================

# Edit /etc/pam.d/sshd
sudo vi /etc/pam.d/sshd

# Add the following line at the top of the auth section:
# auth required pam_google_authenticator.so

# ============================================
# PART 4: CONFIGURE SSH
# ============================================

# Edit /etc/ssh/sshd_config
sudo vi /etc/ssh/sshd_config

# Set:
# KbdInteractiveAuthentication yes
# PasswordAuthentication yes

# The KbdInteractiveAuthentication setting enables the challenge-response
# prompt that the PAM module uses.

# ============================================
# PART 5: RESTART SSH
# ============================================

sudo systemctl restart sshd

# The SSH service reloads the configuration.

# ============================================
# PART 6: TEST THE LOGIN
# ============================================

# From a different terminal:
ssh user@server

# Output:
# Password: ********
# Verification code: 123456

# The user must provide the password and the TOTP code.
# If the code is correct, the login succeeds.
# If the code is wrong or expired, the login fails.

# ============================================
# PART 7: THE EMERGENCY SCRATCH CODES
# ============================================

# The scratch codes are single-use backup codes.
# If the phone is lost, the user can use a scratch code.
# Each scratch code works once and is then invalidated.

# Store the scratch codes in a safe place.
# Do not store them on the same device as the authenticator app.

# ============================================
# PART 8: THE AUTH LOG
# ============================================

sudo tail /var/log/auth.log

# Output:
# sshd[1234]: Accepted keyboard-interactive/pam for user from 192.168.1.100 port 54321 ssh2

# The log records the successful MFA login.

# ============================================
# PART 9: THE SECURITY BENEFIT
# ============================================

# With MFA enabled:
# - A stolen password is not enough to log in.
# - The attacker must also have the TOTP code.
# - The TOTP code changes every 30 seconds.
# - The code is generated locally on the user's device.

# ============================================
# PART 10: THE RECOVERY PLAN
# ============================================

# If the user loses the phone:
# 1. Use a scratch code to log in.
# 2. Re-run google-authenticator to generate a new secret.
# 3. Scan the new QR code with a new device.
# 4. Store the new scratch codes.

# If the user loses the phone and the scratch codes:
# 1. Contact the system administrator.
# 2. The administrator removes the ~/.google_authenticator file.
# 3. The user logs in with the password only.
# 4. The user re-enrolls MFA immediately.

# The recovery plan is part of the MFA policy.
# Without it, a lost phone means a locked-out user.

The ten parts cover installing the module, generating the secret, configuring PAM, configuring SSH, restarting the service, testing the login, the scratch codes, the auth log, the security benefit, and the recovery plan.

Quick Reference

The Three Factors

Factor	Category	Examples
Something you know	Knowledge	Password, PIN, passphrase
Something you have	Possession	Security key, authenticator app, SMS code
Something you are	Inherence	Fingerprint, face scan, iris scan

The MFA Methods by Strength

Method	Strength	Vulnerabilities
SMS/Voice	Weakest	SIM swap, phishing
Authenticator app	Moderate	Phishing
Push + number matching	Strong	MFA fatigue (mitigated)
Hardware key (FIDO2)	Strongest	Physical loss
Passkeys	Strongest	Device loss

The Linux MFA Setup

Step	Command
Install module	`sudo apt install libpam-google-authenticator`
Generate secret	`google-authenticator`
Configure PAM	Add `auth required pam_google_authenticator.so` to `/etc/pam.d/sshd`
Configure SSH	Set `KbdInteractiveAuthentication yes` in `/etc/ssh/sshd_config`
Restart SSH	`sudo systemctl restart sshd`

The MFA Vulnerabilities

Attack	Description	Mitigation
Credential stuffing	Reusing stolen passwords	MFA stops it
Phishing	Fake login pages	FIDO2 is phishing-resistant
SIM swap	Transferring phone number	Use app-based or hardware MFA
MFA fatigue	Bombarding with push notifications	Number matching, rate limiting
Token theft	Stealing session tokens	Phishing-resistant MFA

Best Practices

✅ Do This:

# Use hardware security keys for the strongest protection
# FIDO2/WebAuthn keys are phishing-resistant                          # ✅

# Use authenticator apps instead of SMS when possible
# SMS is vulnerable to SIM-swap attacks                               # ✅

# Enable number matching for push notifications
# Defends against MFA fatigue attacks                                 # ✅

# Store scratch codes in a safe place
# They are the recovery path if the device is lost                    # ✅

# Require MFA for privileged accounts
# Administrators are the highest-value targets                        # ✅

❌ Don’t Do This:

# Don't use two passwords and call it MFA
# That is two-step verification, not MFA                              # ❌

# Don't rely on SMS alone for high-value accounts
# Use a stronger factor                                               # ❌

# Don't store scratch codes on the same device as the authenticator
# If the device is lost, both are lost                                # ❌

# Don't forget the recovery plan
# A lost phone without a recovery path means a locked-out user        # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
User locked out	Lost device, no scratch code	Administrator removes `~/.google_authenticator`
MFA prompt not appearing	SSH config wrong	Check `KbdInteractiveAuthentication`
Code rejected	Clock skew	Sync the device clock
MFA fatigue	Too many push prompts	Enable number matching
SIM swap	SMS used as factor	Switch to app-based or hardware MFA

Real-World Examples

1. SMS Code

# A six-digit code sent to the phone

2. Authenticator App

# A TOTP code generated every 30 seconds

3. Hardware Key

# A YubiKey plugged into the USB port

4. Biometric

# A fingerprint scan on the phone

5. SSH MFA

# Password + TOTP code

6. Sudo MFA

# Add the PAM module to /etc/pam.d/sudo

7. Scratch Code

# A one-time backup code

8. Auth Log

tail /var/log/auth.log

9. MFA Fatigue Defense

# Number matching for push notifications

10. Recovery Plan

# Administrator removes the MFA file

Visual

The Three Factors

┌──────────────────────────────────────────────┐
│  SOMETHING YOU KNOW                          │
│    Password, PIN, passphrase                 │
│                                              │
│  SOMETHING YOU HAVE                          │
│    Security key, authenticator app, SMS      │
│                                              │
│  SOMETHING YOU ARE                           │
│    Fingerprint, face scan, iris scan         │
│                                              │
│  MFA requires two from DIFFERENT categories. │
│                                              │
└──────────────────────────────────────────────┘

The MFA Login Flow

┌──────────────────────────────────────────────┐
│  MFA LOGIN FLOW                              │
│                                              │
│  1. User enters username                     │
│       │                                      │
│       ▼                                      │
│  2. User enters password (factor 1)          │
│       │                                      │
│       ▼                                      │
│  3. Server verifies the password             │
│       │                                      │
│       ▼                                      │
│  4. User provides second factor              │
│     (TOTP code, security key, biometric)     │
│       │                                      │
│       ▼                                      │
│  5. Server verifies the second factor        │
│       │                                      │
│       ▼                                      │
│  6. Access granted                           │
│                                              │
└──────────────────────────────────────────────┘

The MFA Strength Spectrum

┌──────────────────────────────────────────────┐
│  WEAKEST                                     │
│    SMS / Voice codes                         │
│       │                                      │
│       ▼                                      │
│    Authenticator app (TOTP)                  │
│       │                                      │
│       ▼                                      │
│    Push + number matching                    │
│       │                                      │
│       ▼                                      │
│    Hardware key (FIDO2/WebAuthn)             │
│       │                                      │
│       ▼                                      │
│  STRONGEST                                   │
│                                              │
│  Phishing resistance increases upward.       │
│                                              │
└──────────────────────────────────────────────┘

The Linux MFA Stack

┌──────────────────────────────────────────────┐
│  USER                                        │
│    └─ Password + TOTP code                   │
│                                              │
│  SSH                                         │
│    └─ KbdInteractiveAuthentication           │
│                                              │
│  PAM                                         │
│    └─ pam_google_authenticator.so            │
│                                              │
│  AUTH LOG                                    │
│    └─ /var/log/auth.log                      │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
MFA definition	Two or more different authentication factors
Three factors	Knowledge, possession, inherence
2FA vs MFA	2FA is a type of MFA; two-step verification is not
SMS	Weakest method
FIDO2 hardware key	Strongest method
Linux MFA	PAM + Google Authenticator
SSH config	`KbdInteractiveAuthentication yes`
PAM config	`auth required pam_google_authenticator.so`
Scratch codes	One-time backup codes
Recovery plan	Required for lost devices
LFCA weight	Security Fundamentals, 14–16%

Key takeaways:

MFA requires two or more different authentication factors. The three factors are something you know (password), something you have (security key), and something you are (biometric). Two passwords are two-step verification, not MFA .
MFA is one of the most effective security controls. It protects against credential stuffing, phishing, and password reuse. Microsoft reports that MFA can prevent over 99% of account compromise attempts .
Not all MFA methods are equally strong. SMS codes are the weakest because they are vulnerable to SIM-swap attacks. Hardware security keys (FIDO2/WebAuthn) are the strongest because they are phishing-resistant .
MFA fatigue is a real attack. An attacker bombards the user with push notifications until the user approves one. Number matching and rate limiting defend against this attack .
Linux supports MFA for SSH through PAM. The pam_google_authenticator module adds a TOTP second factor. The setup involves installing the module, generating a secret, configuring PAM, and configuring SSH .
Scratch codes are the recovery path. They are one-time backup codes for when the primary MFA device is lost. They must be stored securely and separately from the device .
A recovery plan is mandatory. If a user loses their device and their scratch codes, the administrator must be able to remove the MFA enrollment so the user can log in and re-enroll .

Remember: MFA is the layer that catches the attacker after the password has already failed. It requires proof from at least two different categories. The password is the knowledge factor. The phone, the security key, or the authenticator app is the possession factor. The fingerprint is the inherence factor. SMS is the weakest. FIDO2 is the strongest. Linux implements MFA through PAM. The scratch codes are the recovery path. The recovery plan is mandatory. MFA is not perfect, but it is vastly superior to passwords alone.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!