Multi-Factor Authentication (MFA)

# CHAPTER 12

Multi-Factor Authentication (MFA) #

1. Introduction #

2. Learning Objectives #

• Define the three core factors of authentication.

• Understand the mechanics of TOTP (Time-Based One-Time Password) Authenticator apps.

• Architect the multi-step login workflow required for MFA.

• Explain the role of backup recovery codes.

3. Beginner-Friendly Explanation #

• Single-Factor (Password): The vault has a standard keyhole. If someone steals your key, they can open the vault. This is dangerous.

• Two-Factor (2FA / MFA): The vault has a keyhole AND a retinal scanner. Even if a thief steals your key, they cannot open the vault because they do not have your eyeball.

By requiring two completely different *types* of proof (Something you know + Something you have), the difficulty of hacking an account increases exponentially. A hacker operating from a different country might steal your password, but they cannot physically steal your smartphone.

4. The Three Factors of Authentication #

1. 1. Knowledge Factor: Something you know (Password, PIN, Security Question).

1. 2. Possession Factor: Something you physically have (Smartphone with Google Authenticator, SMS Text, YubiKey Hardware USB).

1. 3. Inherence Factor: Something you physically are (Fingerprint, FaceID).

*Note: Requiring a Password AND a PIN is NOT Multi-Factor. It is Single-Factor (Knowledge) applied twice. It must be two different categories.*

5. Types of Possession Factors #

• SMS / Text Messages: The server texts a 6-digit code to the user. (Widely used, but considered insecure by experts due to "SIM Swapping" attacks).

• Email Links: The server emails a magic link. (Weak, because if the user's password was stolen, their email password is likely stolen too).

• TOTP Authenticator Apps (Google/Authy): The industry standard. The server and the user's phone share a secret math equation. Every 30 seconds, the math equation generates a new 6-digit code.

6. How TOTP (Authenticator Apps) Work #

1. 1. Setup: Your server generates a random base32 "Secret Key" (e.g., JBSWY3DPEHPK3PXP). It converts this key into a QR code.

1. 2. Scanning: The user scans the QR code with their Google Authenticator app. The app saves the Secret Key.

1. 3. The Algorithm: Both your Server and the User's Phone run the exact same mathematical algorithm: HMAC-SHA1(Secret Key + Current Unix Time).

1. 4. The Code: Because both devices have the same Secret Key and the exact same time, they both generate the exact same 6-digit code (e.g., 482 911). This code changes every 30 seconds as the clock ticks.

1. 5. Verification: The user types 482 911 into the website. The server calculates the math. If the server's answer matches the user's answer, access is granted!

7. The MFA Login Workflow (Architecture) #

Step 1: First Factor Verification The user submits Email and Password.

// POST /api/login
if (password_verify(password, dbHash)) {
    if (user.mfa_enabled === true) {
        // Do NOT generate a final JWT yet!
        // Generate a temporary "Half-Login" token that ONLY allows access to the MFA route
        const tempToken = jwt.sign({ userId: user.id, mfa_pending: true }, SECRET);
        return res.json({ mfaRequired: true, token: tempToken });
    } else {
        // Generate final JWT
    }
}

Step 2: Second Factor Verification The frontend receives the tempToken, sees mfaRequired: true, and redirects the user to a screen asking for their 6-digit code. The user types the code and submits it to a new route.

// POST /api/verify-mfa
const { tempToken, mfaCode } = req.body;
const decoded = jwt.verify(tempToken, SECRET);

if (decoded.mfa_pending === true) {
    const userSecret = db.getMFASecret(decoded.userId);
    
    // Use a library like 'otplib' or 'speakeasy' to do the TOTP math
    const isValid = totp.verify({ token: mfaCode, secret: userSecret });
    
    if (isValid) {
        // SUCCESS! Generate the FINAL, full-access JWT
        const finalToken = jwt.sign({ userId: decoded.userId, role: 'admin' }, SECRET);
        return res.json({ token: finalToken });
    }
}

8. Backup Recovery Codes #

9. Best Practices #

• Rate Limit the MFA Endpoint: Hackers might try to brute-force the 6-digit code. Because there are only 1,000,000 possible combinations, a fast script could guess it within the 30-second window. You MUST strictly rate-limit the /api/verify-mfa route to a maximum of 5 attempts before locking the account temporarily.

10. Common Mistakes #

• Time Drift: If the server's internal clock is 2 minutes fast, the server's math will generate a different 6-digit code than the user's phone, causing verification to fail constantly. Ensure your production server is synchronized using NTP (Network Time Protocol), and configure your TOTP library to accept a "window" of +/- 1 time step (allowing codes from 30 seconds ago to still work).

11. Exercises #

1. 1. Explain why SMS text messages are considered a less secure Multi-Factor Possession factor compared to TOTP Authenticator apps. What is a SIM Swapping attack?

12. Coding Challenges #

• Challenge: Research the NPM package speakeasy (for Node.js) or pyotp (for Python). Write a 5-line conceptual script that generates a random base32 secret key, and then generates the current 6-digit TOTP code based on that secret.

13. MCQs with Answers #

14. Interview Questions #

• Q: Describe the architectural workflow of implementing MFA in a stateless JWT-based backend. How do you securely pause the login process between the password check and the TOTP code submission without losing track of the user?

• Q: Explain the cryptographic mechanism behind a Time-Based One-Time Password (TOTP) system. What happens if the server's clock drifts significantly out of sync with global time?

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #