MFA & Step-up Authentication

MFA adds a second proof of identity beyond a password (like an authenticator app or a hardware key). It reduces account takeover from password leaks.

Mental model

1. Enrollment: user binds a factor to their account (TOTP, WebAuthn, push, SMS, etc.).
2. Challenge: on login or risky action, server requests proof from that factor.
3. Step-up: require MFA for high-risk actions (email/password/MFA changes, payouts).
4. Recovery: if user loses the factor, recovery must be at least as strong as login.

In real incidents: these issues usually slip through because everything looks “fine” in happy-path testing — until one weird request hits production.

Common failure modes (what goes wrong)

A) “MFA is enabled” but not enforced

• Root cause: MFA checked only at login, not at sensitive actions.
• Attacker mindset: “If I get a session once, can I change email/password without step-up?”
• Defense: step-up on sensitive actions; require recent authentication + MFA.

B) Weak enrollment protection

• Root cause: attacker with partial access can enroll their own factor without step-up.
• Defense: enrollment requires step-up; notify user; log and rate limit.

C) Weak recovery bypasses MFA

• Root cause: recovery uses weak signals (guessable info, insecure email flows, no delays).
• Attacker mindset: “Recovery is the back door.”
• Defense: high-assurance recovery: verified channels, delays, device checks, manual review for high-value accounts.

D) Poor session policies

• Root cause: long sessions, no re-auth on risky changes, no device/session management.
• Defense: step-up + recent auth windows + per-device sessions + revocation on security events.

Defensive patterns (Node.js concepts)

Step-up middleware (recent auth + MFA)

// ✅ Concept: require recent auth + MFA verification before sensitive endpoints
function requireStepUp(req, res, next) {
  const recent = typeof req.session?.authTime === "number" && (Date.now() - req.session.authTime) < 10 * 60 * 1000;
  const mfaOk = req.session?.mfaVerified === true;
  if (!recent || !mfaOk) return res.status(403).json({ ok: false, error: "Step-up required" });
  next();
}

app.post("/change-email", requireStepUp, (req, res) => { /* ... */ });
app.post("/change-password", requireStepUp, (req, res) => { /* ... */ });
app.post("/mfa/enroll", requireStepUp, (req, res) => { /* ... */ });

Defensive workflow notes

• Mark sessions as mfaVerified only after successful challenge.
• Reset mfaVerified after a short time window or after risky changes.
• Revoke other sessions when MFA settings change.

Safe validation (defensive verification)

• Confirm step-up is required for sensitive actions, not only for login.
• Confirm enrollment requires step-up and is logged + notified.
• Confirm recovery does not silently bypass MFA without stronger proof; includes delays/verification.
• Confirm session and device management exists; revoke sessions on MFA changes.
• Confirm rate limiting and monitoring on MFA challenges and recovery attempts.

Interview Questions & Answers (Easy → Hard)

Easy

1. What is MFA?
   A: Plain: second proof besides password. Deep: reduces takeover from leaked passwords.
2. Why isn’t MFA a silver bullet?
   A: Plain: recovery can bypass it. Deep: weak recovery/enrollment breaks the model.
3. What is step-up authentication?
   A: Plain: ask for extra proof for risky actions. Deep: protects sensitive changes and payouts.
4. What’s a “recent auth” window?
   A: Plain: recently confirmed identity. Deep: require re-auth/MFA before sensitive actions if session is old.
5. Where do you enforce MFA?
   A: Plain: at login and critical actions. Deep: step-up for email/password/MFA changes and high-risk operations.
6. What telemetry matters?
   A: Plain: watch failed attempts. Deep: challenge failures, recovery attempts, device changes, enrollment events.
7. What’s the biggest design risk?
   A: Plain: weak recovery. Deep: attackers use recovery as the primary bypass path.

Medium

1. Scenario: MFA enabled but email change doesn’t require it. Risk?
   A: Plain: takeover persists. Deep: attacker changes email then resets; fix with step-up + alerts.
2. Scenario: enrollment doesn’t require step-up. Risk?
   A: Plain: attacker adds their own factor. Deep: protect enrollment with step-up + notifications.
3. Scenario: SMS fallback. What are trade-offs?
   A: Plain: convenient but weaker. Deep: prefer stronger factors; protect fallback with step-up and risk controls.
4. Follow-up: how to handle lost phone?
   A: Plain: recovery. Deep: verified channel + delays + revoke sessions + audit trail.
5. Scenario: push MFA fatigue. Defense?
   A: Plain: reduce spamming. Deep: number matching, rate limits, risk-based prompts, anomaly detection.
6. Follow-up: do you revoke sessions after MFA changes?
   A: Plain: yes. Deep: security event—revoke other sessions and require step-up again.
7. Scenario: remember-this-device. How do you secure?
   A: Plain: bind to device. Deep: device tokens with rotation and revocation; detect anomalies.

Hard

1. How do you design high-assurance recovery?
   A: Plain: stronger proof. Deep: verified channels, delays, device checks, manual review for high-risk accounts.
2. How do you prevent bypass via support processes?
   A: Plain: policy controls. Deep: strict support verification, audit, least privilege, and approvals.
3. What’s your step-up policy for sensitive actions?
   A: Plain: always require. Deep: recent auth + MFA, plus risk signals for unusual behavior.
4. How do you protect MFA secrets (TOTP/WebAuthn) server-side?
   A: Plain: store safely. Deep: encrypted at rest, limited access, rotation policy, strong audit.
5. Scenario: incident with takeover. What do you do?
   A: Plain: lock and recover. Deep: revoke sessions, reset factors, notify, audit changes, tighten policies.
6. Follow-up: how do you measure MFA effectiveness?
   A: Plain: lower takeover rate. Deep: monitor takeover metrics, recovery abuse rate, and friction vs security trade-offs.

Exploitation progression (attacker mindset)

• Skip the factor: attackers hunt endpoints that don’t require step-up (email/password change).
• Enroll their own factor: if enrollment isn’t protected, they make themselves “the second factor.”
• Abuse recovery: weak recovery becomes the main bypass path.
• Keep access: long sessions and missing revocation make takeover persistent.

Checklist

• Step-up required for sensitive actions (email/password/MFA changes, payouts).
• Enrollment protected by step-up and generates alerts/audit logs.
• Recovery is high-assurance (verified channel, delays, device/risk checks, manual review for high value).
• Session policies: recent-auth window, per-device sessions, revoke on security events.
• Rate limits and monitoring on challenges and recovery.

Remediation playbook

1. Implement step-up enforcement for sensitive actions with recent-auth window.
2. Protect MFA enrollment with step-up and user notifications.
3. Harden recovery: stronger verification, delays, and revoke sessions after recovery.
4. Add per-device session listing and revocation; revoke sessions on MFA changes.
5. Add rate limits and monitoring; create IR playbook for takeover and recovery abuse.
6. Add tests: step-up coverage for sensitive endpoints and recovery bypass attempts.