Risk-based Authentication
MFA 不一定要每次都跳出來。
真正成熟的登入系統會問：
這次登入或操作的風險高不高？
如果風險高，要提高驗證強度。
如果風險低，盡量不要打擾使用者。這就是 Risk-based Authentication，也常被稱為 Adaptive Authentication。
它的目標不是取代 MFA，而是讓 MFA 更聰明：
低風險少打擾；
高風險強驗證。例如同一個使用者：
每天早上從自己的筆電、同一城市登入和：
凌晨從陌生國家、Tor exit node、剛輸錯很多次密碼後登入不應該被當成同一種風險。
一、 一句話回答
如果面試官問：
Risk-based Authentication 是什麼？怎麼設計？
可以先回答：
Risk-based Authentication 是根據登入或操作的上下文動態調整驗證強度的機制。系統會收集風險訊號，例如新裝置、新地點、IP reputation、VPN/Tor、登入失敗次數、裝置指紋、行為異常、已知外洩密碼、敏感操作等，計算風險等級；低風險時可讓使用者正常登入，高風險時要求 step-up authentication，例如 TOTP、Passkey、fresh MFA、重新輸入密碼，甚至拒絕登入或鎖定帳號。成熟設計會把 session 的 assurance level 記錄下來，敏感操作要求近期重新驗證，而不是只看 session 是否存在。同時也要避免風險訊號被 spoof、避免 fallback 比主要 MFA 還弱，並記錄 audit log 與安全通知。
短一點可以說：
Risk-based Authentication 是把「是否加驗」從固定規則，
改成根據風險上下文動態決定。二、 它解決什麼問題
如果每次登入都要求 MFA：
- 安全性清楚。
- 但使用者容易疲勞。
- 可能導致使用者關閉 MFA。
- 客服與恢復流程壓力增加。
如果從不要求 MFA：
- 體驗很好。
- 但密碼外洩後很危險。
Risk-based Authentication 嘗試折衷：
| 情境 | 系統反應 |
|---|---|
| 常用裝置 + 常用地點 + 低風險操作 | 不加驗或低摩擦 |
| 新裝置 + 新地點 | 要求 MFA |
| Tor / 高風險 IP | 要求強 MFA 或拒絕 |
| 修改密碼 / email / MFA | 要求 fresh MFA |
| 大量失敗登入後成功 | 要求 step-up |
| 管理員操作 | 要求高強度驗證 |
這不是「少做安全」，而是：
把使用者摩擦放在最需要的地方。三、 Risk-based、Adaptive、Step-up 的差別
| 名稱 | 意義 |
|---|---|
| Risk-based Authentication | 根據風險決定驗證要求 |
| Adaptive Authentication | 根據上下文動態調整驗證方式，常和 risk-based 混用 |
| Step-up Authentication | 在登入後或操作前提高驗證強度 |
| Reauthentication | 要求使用者重新證明身份 |
| Fresh MFA | 要求近期剛完成 MFA，而不是很久以前完成 |
| Session Assurance | session 目前達到的驗證強度 |
例子：
使用者已登入 2 小時。
現在要修改付款資訊。
系統要求重新通過 Passkey 或 TOTP。這就是 step-up authentication，也是一種 reauthentication。
四、 常見風險訊號
風險訊號不是越多越好，而是要可解釋、可用、可防濫用。
常見訊號：
| 訊號 | 說明 |
|---|---|
| 新裝置 | 使用者從未見過的 device id / browser 登入 |
| 新地點 | 國家、城市、時區異常 |
| IP reputation | datacenter、VPN、proxy、Tor、已知惡意 IP |
| 登入失敗 | 短時間內多次失敗後成功 |
| impossible travel | 短時間內從不可能距離的兩地登入 |
| 已知外洩密碼 | 密碼出現在 breach corpus |
| 行為異常 | 操作時間、使用模式突然改變 |
| 裝置完整性 | 是否 managed device、jailbreak/root，視平台 |
| 帳號狀態 | 剛重設密碼、剛恢復帳號、剛變更 MFA |
| 操作敏感度 | 修改 email、提款、刪除資料、產生 API key |
注意：
風險訊號不是身份證明。例如裝置指紋只能輔助判斷，不能當作強身份因素。
五、 風險分數模型
最簡單可以用規則。
例如：
function calculateRiskScore(context) {
let score = 0
if (context.isNewDevice) score += 30
if (context.isNewCountry) score += 30
if (context.isTorExitNode) score += 50
if (context.failedAttemptsLastHour > 5) score += 25
if (context.passwordKnownCompromised) score += 60
if (context.isSensitiveAction) score += 40
if (context.hasRecentMfa) score -= 30
if (context.isManagedDevice) score -= 15
return Math.max(0, Math.min(score, 100))
}再映射成決策：
function decideAuthAction(score) {
if (score < 30) return 'allow'
if (score < 60) return 'require_mfa'
if (score < 85) return 'require_strong_mfa'
return 'deny_or_manual_review'
}這不是唯一做法，但面試時很容易講清楚。
成熟系統會把規則、模型、風險事件、人工調整、誤判回饋都納入治理。
六、 Step-up Authentication
Step-up 的意思是：
你已經登入了，
但現在要做更敏感的事，所以要提高驗證強度。常見觸發：
- 修改密碼。
- 修改 email。
- 修改手機。
- 新增 / 解除 MFA。
- 新增第三方登入。
- 產生 API key。
- 查看敏感資料。
- 付款 / 提款。
- 刪除帳號。
- 管理員改權限。
Step-up 可以要求：
- 重新輸入密碼。
- TOTP。
- Passkey。
- WebAuthn security key。
- 管理員再次確認。
高風險操作建議使用：
fresh MFA也就是近期剛通過 MFA，而不是「這個 session 兩天前曾通過 MFA」。
七、 Session Assurance
session 不應該只有：
logged_in = true可以記錄更細的驗證狀態：
type Session = {
userId: string
authenticatedAt: Date
passwordVerifiedAt: Date | null
mfaVerifiedAt: Date | null
phishingResistantVerifiedAt: Date | null
assuranceLevel: 'aal1' | 'aal2' | 'aal3'
riskLevel: 'low' | 'medium' | 'high'
}敏感操作可以要求：
function requireFreshMfa(session, maxAgeMinutes = 10) {
if (!session.mfaVerifiedAt) {
throw new Error('MFA_REQUIRED')
}
const age = Date.now() - session.mfaVerifiedAt.getTime()
if (age > maxAgeMinutes * 60 * 1000) {
throw new Error('FRESH_MFA_REQUIRED')
}
}更高風險可以要求：
phishing-resistant MFA within 10 minutes例如 Passkey / WebAuthn security key。
八、 Reauthentication After Risk Events
OWASP Authentication Cheat Sheet 明確提到高風險事件後應重新驗證。
常見 risk events：
- suspicious account activity。
- account recovery。
- password reset。
- MFA reset。
- 新裝置登入。
- 異常地點登入。
- 高風險交易。
- 權限提升。
- 管理員操作。
重新驗證後可以做：
- 旋轉 session id。
- 更新 session assurance。
- 撤銷其他 session。
- 寄安全通知。
- 記錄 audit log。
- 限制短時間內敏感操作。
重點：
風險事件後不只是問一次 OTP，
也要重新評估 session 和帳號狀態。九、 風險決策結果
風險判斷後不只有 allow / deny。
常見決策：
| 決策 | 說明 |
|---|---|
| allow | 低風險，正常通過 |
| allow with notification | 通過但寄通知 |
| require MFA | 要求一般 MFA |
| require strong MFA | 要求 Passkey / WebAuthn / security key |
| require password reset | 密碼可能外洩 |
| deny | 風險太高，拒絕 |
| lock account | 暫時鎖定並通知 |
| manual review | 高價值或企業帳號人工審查 |
例如：
新裝置：require MFA
Tor + 新國家：require strong MFA
已知外洩密碼：require password reset
管理員從陌生地點登入：require security key十、 風險資料模型
可以有幾張表：
create table auth_events (
id uuid primary key,
user_id uuid,
event_type text not null,
ip inet,
user_agent text,
device_id text,
country text,
city text,
risk_score int,
risk_level text,
decision text,
created_at timestamp not null
);
create table trusted_devices (
id uuid primary key,
user_id uuid not null references users(id),
device_id_hash text not null,
name text,
last_seen_at timestamp,
created_at timestamp not null,
revoked_at timestamp,
unique (user_id, device_id_hash)
);
create table step_up_challenges (
id uuid primary key,
user_id uuid not null references users(id),
purpose text not null,
required_level text not null,
expires_at timestamp not null,
verified_at timestamp,
created_at timestamp not null
);重點：
- auth_events 用於稽核和風險模型。
- trusted_devices 不是強身份，只能降低風險。
- step_up_challenges 用來隔離敏感操作的重新驗證流程。
十一、 Trusted Device 的陷阱
很多產品有：
信任這台裝置 30 天這可以改善體驗，但要小心。
Trusted device 不是第二因素。
它只是風險訊號。
風險：
- device cookie 被偷。
- 共用電腦被信任。
- XSS 竊取裝置識別。
- 使用者賣掉或遺失裝置。
- 瀏覽器 profile 同步。
設計建議：
- 只在通過 MFA 後才能信任裝置。
- 信任期限有限。
- 使用者可查看並撤銷 trusted devices。
- 高風險操作仍要求 fresh MFA。
- 管理員帳號縮短或禁用 trusted device。
十二、 不要讓 fallback 變弱點
Risk-based Authentication 常見錯誤：
高風險時要求 SMS OTP，
但 SMS OTP 可以用很弱的客服流程重設。或：
Passkey 登入很強，
但忘記 passkey 時只要 email OTP 就能關閉所有 MFA。安全性取決於最弱路徑。
所以要一起檢查：
- 忘記密碼。
- 忘記 MFA。
- 解除 trusted device。
- 重設手機。
- 客服流程。
- 管理員代操作。
- 帳號恢復。
高風險操作應避免降級到更弱因素。
十三、 使用者體驗設計
Risk-based Authentication 的好體驗不是讓使用者困惑。
不好的提示：
風險分數 72，請驗證。比較好的提示：
我們偵測到你正在使用新裝置登入，請完成額外驗證。或：
你正在修改安全設定，請再次確認是你本人操作。不要透露太多可被攻擊者調整的細節。
例如不要說：
因為你的 IP reputation 太低。攻擊者會換 IP 測試。
十四、 常見錯誤
1. 把裝置指紋當 MFA
錯誤：
這台裝置看起來熟悉，所以不需要任何驗證。正確：
裝置指紋只能降低風險，不能取代使用者身份驗證。2. 高風險操作只看 session
錯誤：
session 有效，所以可以改 email。正確：
修改 email 要求 fresh MFA 或 reauthentication。3. 風險分數不可解釋
錯誤：
模型說高風險，但工程師不知道為什麼。正確：
保留 risk factors，讓稽核、客服和調校有依據。4. 不記錄風險事件
錯誤：
登入被要求 MFA，但沒有任何 auth event。正確：
記錄 risk score、decision、signals、challenge result。5. 永久信任裝置
錯誤：
信任裝置永不過期。正確：
有期限、可撤銷，高風險操作仍加驗。6. 風險訊號可以被簡單 spoof
錯誤：
只看 User-Agent 字串判斷是否新裝置。正確：
使用多個訊號綜合判斷，並假設單一訊號可能被偽造。十五、 面試追問題庫
Q1：Risk-based Authentication 是什麼？
它是根據登入或操作上下文動態決定是否加驗的機制。常見訊號包括新裝置、新地點、IP reputation、登入失敗、敏感操作、已知外洩密碼等。風險高時要求 MFA、強 MFA、重新驗證或拒絕。
Q2：Step-up Authentication 是什麼？
使用者已登入，但在做敏感操作前，系統要求提高驗證強度，例如重新輸入密碼、TOTP、Passkey 或 WebAuthn security key。
Q3：Fresh MFA 是什麼？
Fresh MFA 是近期剛完成的 MFA。它避免使用者很久以前通過 MFA 後，長時間 session 仍可做高風險操作。常見做法是敏感操作要求 5 到 15 分鐘內通過 MFA。
Q4：Trusted device 算不算 MFA？
不算。Trusted device 只是風險訊號，代表這台裝置曾被使用者信任。它不能單獨證明使用者本人，且可能被偷、共用或同步。
Q5：風險訊號有哪些？
常見包含新裝置、新地點、IP reputation、Tor/VPN、impossible travel、登入失敗次數、已知外洩密碼、帳號剛恢復、敏感操作、管理員權限等。
Q6：風險高時一定要拒絕登入嗎？
不一定。可以根據風險等級採取不同動作：要求 MFA、要求強 MFA、寄通知、要求密碼重設、暫時鎖定、人工審核或拒絕。
Q7：Risk-based Authentication 最大的坑是什麼？
最大的坑是 fallback 太弱、風險訊號可被偽造、決策不可解釋、以及把裝置或地點訊號誤當成身份因素。安全性仍取決於完整身份生命週期。
十六、 實作題
題目一：設計風險分數
請設計一個 login risk score，至少考慮：
- 新裝置。
- 新國家。
- IP reputation。
- 登入失敗次數。
- 已知外洩密碼。
- 是否 managed device。
- 是否最近通過 MFA。
並輸出：
allow
require_mfa
require_strong_mfa
deny_or_review題目二：設計敏感操作 fresh MFA
情境：
使用者要修改登入 email。請設計：
- session 檢查。
- 是否最近通過 MFA。
- 若沒有，建立 step-up challenge。
- 通過後允許修改。
- 修改後寄通知。
- 記錄 audit log。
題目三：設計 trusted device
要求：
- 只能在通過 MFA 後建立。
- 有效期 30 天。
- 使用者可撤銷。
- 管理員帳號不允許或縮短期限。
- 新 IP / 新地點仍可要求加驗。
- 不可把 trusted device 當作 MFA。
十七、 資深視角
1. Risk-based 不是少做 MFA，而是做對 MFA
固定要求 MFA 很簡單，但體驗成本高。
Risk-based 的成熟點在於：
把安全摩擦放在風險最高的位置。這需要資料、規則、稽核、回饋與產品設計一起配合。
2. Session 要有強度，而不是只有存在與否
資深設計會區分：
已登入
已通過 MFA
剛通過 MFA
已通過 phishing-resistant MFA不同操作需要不同 assurance。
這比單純 isAuthenticated 更接近真實安全需求。
3. 風險訊號要能被治理
風險模型會誤判。
所以要有：
- 可觀測事件。
- 可解釋 risk factors。
- 安全團隊可調整規則。
- 客服可理解但不能繞過安全。
- 使用者可收到合理通知。
黑盒模型如果不能治理，會變成新的風險。
4. 高風險帳號要有更高基準
不是所有帳號都一樣。
管理員、財務、醫療、政府、高價值創作者、企業 owner，都應該有更高基準：
- always-on MFA。
- phishing-resistant MFA。
- 短 session。
- 更嚴格 step-up。
- 禁用弱 fallback。
- 更完整 audit log。
總結
| 問題 | 回答重點 |
|---|---|
| Risk-based Authentication | 根據風險上下文動態調整驗證強度 |
| Adaptive Authentication | 和 risk-based 類似，強調動態調整 |
| Step-up | 敏感操作前提高驗證強度 |
| Fresh MFA | 近期剛通過 MFA |
| Session Assurance | session 目前的驗證強度 |
| 風險訊號 | 新裝置、新地點、IP reputation、失敗次數、敏感操作 |
| Trusted device | 風險訊號，不是 MFA |
| 高風險決策 | MFA、強 MFA、拒絕、鎖定、人工審查 |
| 常見錯誤 | fallback 太弱、只看 session、訊號可 spoof、不可解釋 |
一句完整的面試回答可以是：
Risk-based Authentication 是根據登入或操作的上下文動態調整驗證強度。系統會收集新裝置、新地點、IP reputation、VPN/Tor、登入失敗次數、已知外洩密碼、敏感操作、帳號剛恢復等風險訊號，計算風險等級。低風險時可正常登入；中風險要求 MFA；高風險要求 Passkey / WebAuthn 等強 MFA，甚至拒絕或人工審查。成熟設計會把 session assurance 記錄下來，區分已登入、已通過 MFA、剛通過 MFA、已通過釣魚抗性 MFA，敏感操作要求 fresh MFA。它的重點不是少做 MFA，而是把加驗放在最需要的位置，同時避免 trusted device 被當成 MFA、fallback 太弱、風險訊號可被偽造，以及沒有 audit log。