📝 Investigation: What security gaps exist in the S280 2FA + password reset im...

Date: 2026-03-27
Time: 19:21:33 UTC
Session: gspace1-280.4
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

What security gaps exist in the S280 2FA + password reset implementation?

Task: Not specified

🎯 Decision Made

Chosen:

4 critical issues identified: (1) backup code race condition — two concurrent requests can consume the same code, (2) tempToken never invalidated after 2FA success — replayable within 5min window, (3) password reset token stored in plaintext in MongoDB — DB compromise = account takeover, (4) trusted device token returned in JSON body (not HttpOnly cookie) AND never actually checked during login (dead code)

Options Considered:

1. Ship as-is for PoC and fix later
2. Fix all 4 critical issues before any testing
3. Fix #4 (plaintext tokens) and #5 (trusted device) now, defer #1 and #3 to next session

💭 Reasoning

Post-implementation security review. Issues #1 and #3 are classic TOCTOU and token-reuse bugs. Issue #4 is a standard security practice (hash tokens at rest, same as bcrypt for passwords). Issue #5 is a gap between spec and implementation — the spec described trusted device cookies but the implementation returns JSON and never reads it back. Additionally: OTP comparison uses === (timing attack vector), TOTP window is implicit not explicit, Redis INCR+EXPIRE is non-atomic.

📁 Files Involved

• libs/libs-api/auth-core/src/lib/services/two-factor.service.ts
• APIs/backend-api/src/app/backend-auth/backend-auth.service.ts
• APIs/backend-api/src/app/backend-auth/two-factor.controller.ts
• APIs/backend-api/src/app/auth/phone-auth.service.ts

🔗 Related

• Decision ID: dev_1774639293673_9fax0rt
• Session: 280
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation