S3 掃描發現：jedi-iam 第二因子與人機驗證（MFA + Turnstile）

掃描日期：2026-09-05 掃描版本：jedi-python-package feature/FR-075 @ 67cb075（乾淨，無未 commit 變更） 工具：Claude Code claude-security plugin v0.10.2.3，effort: low 範圍：jedi-iam/jedi_iam/mfa、jedi-iam/jedi_iam/turnstile，共 34 個受版控檔案 狀態：✅ 已經過工具驗證面板完整審查（單一研究員掃完整個範圍 → 3 人面板逐條投票） 裁決狀態：✅ 已全數處理——F1 CM-1557、F2 CM-1558 均已修（1.21.0 出貨）

• agent 派出/回報：研究員 2（1 主掃描員覆蓋全部 34 檔＋panel 內部另需要一次補充查證，回報 2/2）＋面板 9 票（3 個候選 × 3 票）全數投完
• 面板結果：候選 3 條 → 2 條通過（F1 3/3、F2 2/3）、1 條被面板一致否決（非密碼學安全亂數，0/3）
• 驗證面板狀態：verified（render_report.py 蓋出的官方戳記，非自行宣稱）
• 產出檔案：CLAUDE-SECURITY-20260905-064153-s3/（CLAUDE-SECURITY-RESULTS.md / .jsonl / .sarif / revision stamp），該目錄有自己的 .gitignore 排除版控，本檔為手動摘要進 repo 供裁決追蹤

第一輪試掃在同一塊範圍（OTP + Turnstile）找到過 H-6（OTP 端點無認證無次數限制）與 M-4（Turnstile fallback 到永遠通過的測試金鑰）。這一輪跑完整條含驗證面板後：

• H-6 → 本輪 F1，確認屬實，面板 3/3 一致通過。這次額外查清楚了：密碼路徑（LoginDomainService.is_user_locked_within_limit）有 3 次/15 分鐘的鎖定機制，但 MFA 驗證路徑完全沒有對應控制——兩條路徑走的是不同程式碼，不是同一套邏輯漏鎖一處。FE 有前端計數器（OtpVerification.vue errorCount≥5）但直接打 API 可繞過。
• M-4 → 本輪 F2，確認程式碼行為屬實，面板 2/3 通過（confidence 降為 medium）。這輪多查出一個重要限制：目前出貨的安裝路徑（installer）預設把 TURNSTILE_ENABLED 設為 false，且所有已 commit 的 env 檔在 Turnstile 開啟時都有明確設定金鑰（即使是測試金鑰），所以這條路徑在目前實際部署設定下不會被觸發。程式碼本身仍是不設防的，但反映的是「未來或非標準部署方式的風險」，不是「現在正在裸奔」。
• 舊清單的 L-1（OTP 用非密碼學安全亂數）→ 本輪重新被研究員提出，但面板 3 票一致否決。三位驗證者都指出：舉報者自己承認攻擊機制是「理論上」需要從同一 process 觀察到大量 random 模組的其他輸出才能重建亂數狀態，而整個 codebase grep 後找不到任何這樣的洩漏管道（唯一另一處用到 random 的是從未被實例化的死碼）。這是本輪跑完整驗證面板才篩掉的假陽性，印證了母卡強調的「跑完整條含驗證面板」的價值。

F1 OTP／MFA 驗證端點無次數限制，可暴力猜出 6 位數驗證碼

• 檔案：jedi-iam/jedi_iam/mfa/infra/email/adapter/email_adapter.py:14 EmailAdapter.verify（TOTP 路徑 jedi-iam/jedi_iam/mfa/infra/totp/adapter/totp_adapter.py:11-18 有相同缺口）
• 問題：驗證碼比對只是一行 if stored_code and stored_code == code:，沒有任何次數限制、退避、鎖定機制。呼叫它的 MfaVerifyRoute.post（jedi-iam/jedi_iam/api/routes/otp_route.py:86-114）刻意不掛認證（因為這是登入第二關，此時還沒 access token），驗證通過就直接發出完整的 access/refresh JWT。
• 實查：✅ 屬實，面板 3/3 一致通過。已對照確認密碼路徑確實有獨立的 3 次/15 分鐘鎖定機制（login_domain_service.py:61-76），但這套機制完全沒有被 MFA 驗證路徑呼叫——是兩條分開的程式碼路徑，不是共用邏輯漏設定。唯一存在的節流是 /otp-resend 的 60 秒冷卻，管的是「重發驗證碼」不是「驗證嘗試次數」，對暴力猜碼沒有任何阻擋作用。BE 與 FE 兩邊都查過沒有 nginx/WAF/Flask-Limiter 之類的外部速率限制。
• 影響：攻擊者只要已經拿到受害者的密碼（外洩資料庫、釣魚、密碼重用），完全不需要受害者的 email 或驗證器 app，就能在驗證碼約 300 秒的 Redis TTL 內暴力猜完六位數（100 萬組合），拿到完整 JWT 直接取得帳號控制權，等於 MFA 這道第二關防線形同虛設。
• 前提：① 攻擊者已持有目標帳號的有效密碼；② 沒有外部速率限制擋在 API 前面（目前確認沒有）；③ 該帳號啟用了 MFA。
• 建議修法：比照密碼路徑的鎖定機制，在 EmailAdapter.verify / ToptAdapter.verify（或上一層的 EmailMfaService/TotpMfaService）加上 per-uid 失敗次數計數＋鎖定；每組驗證碼設定總嘗試上限（例如 5 次），超過即讓該碼失效。

F2 Turnstile 人機驗證在忘記設定密鑰時會靜默永遠通過（fail-open）

• 檔案：jedi-iam/jedi_iam/turnstile/verifier.py:38 _resolve_secret_key
• 問題：當設定讀不到 TURNSTILE_SECRET_KEY 時，_resolve_secret_key() 會 fallback 到 Cloudflare 官方文件公開的「永遠通過」測試金鑰。這個值送去真正的 Cloudflare siteverify 端點，不管前端送了什麼 token（甚至空值）都會回傳成功。呼叫端 TurnstileCaptchaVerifier.verify（compliance-manager-be/app/auth/service/login_adapters.py:35-41）只有在明確設 TURNSTILE_ENABLED=false 時才跳過，該旗標預設是 true（config/config.py:286）。fallback 發生時完全沒有 log 警告。
• 實查：✅ 程式碼行為屬實，面板 2/3 通過（confidence 降為 medium，非 3/3 才有的 high）。但這輪額外查清楚了一個重要限制，第一輪沒查到：目前出貨的安裝路徑（scripts/installer/install.sh:1408）預設把 TURNSTILE_ENABLED 寫死為 false，而且目前所有已 commit 的 env 檔（.env / .env.sample / .env.test）在 Turnstile 開啟的情況下都有明確設定金鑰（即使是文件記載的測試金鑰）。也就是說目前實際的部署設定不會踩到這條路徑，一位驗證者因此投了否決票——但另外兩位仍認為這是一段真實、沒有任何防護的程式碼行為，未來任何偏離目前 installer / env 檔慣例的部署方式（例如雲端 SaaS 安裝流程）都可能踩到，且踩到時完全沒有告警訊號，所以維持 MEDIUM 而非直接下架。
• 影響：若真的發生（開了 Turnstile 但沒設金鑰），登入頁的人機驗證形同虛設，任何自動化程式都能無阻礙地打登入 API（帳號鎖定機制仍是獨立的第二道防線，不受此影響）。
• 前提：TURNSTILE_ENABLED=true（預設值）且 TURNSTILE_SECRET_KEY 完全未設定——依目前 installer 與 env 檔慣例，這不是預設會發生的狀態。
• 建議修法：改成 fail closed——只在明確的 dev/debug 旗標同時為真時才允許用測試金鑰頂替，並在每次走到這個 fallback 分支時印出顯眼、會重複出現的警告，讓誤設定不再是靜默的。

本輪掃描完整跑完含驗證面板，render_report.py 蓋出的 verification.status 為 verified。範圍限定在 mfa/ 與 turnstile/ 兩個目錄共 34 個受版控檔案，範圍外（jedi-iam 其他模組、其他 jedi-* 套件）本輪未檢查，不在此份清單的宣稱範圍內。