跳至主要內容
日沐 SunBathe

Appearance

身份驗證安全檢查清單 ​

身份驗證系統最可怕的地方不是你不知道某個技術。

而是：

text
你以為已經做了登入，
但實際上忘了登出、撤銷、rate limit、MFA 恢復、audit log、敏感操作重新驗證。

所以這篇不是再講單一原理，而是整理一份上線前可以逐項檢查的清單。

它適合用在：

  • 新系統設計 review。
  • 登入系統重構。
  • 面試系統設計準備。
  • 安全自查。
  • PR checklist。
  • 上線前驗收。

這份清單會從最基本的帳號密碼，一路檢查到金融/醫療級、高信任身份和後台管理員場景。

一、 一句話回答 ​

如果面試官問：

身份驗證系統上線前要檢查什麼？

可以先回答：

我會從身份生命週期檢查：註冊是否驗證 email/phone 並避免枚舉；密碼是否用 Argon2id/bcrypt 等慢 hash 加 salt 儲存；登入是否有 rate limit、credential stuffing 防護和一致錯誤訊息；Web session cookie 是否設 HttpOnly、Secure、SameSite、隨機 session id 並可撤銷；JWT/refresh token 是否短效、旋轉、可撤銷；忘記密碼 token 是否短效、單次、DB 存 hash；MFA 是否有啟用、停用、恢復和 backup codes；OAuth/OIDC 是否驗證 state、nonce、issuer、audience、redirect URI；敏感操作是否需要重新驗證；後台是否強制 MFA、最小權限和 audit log；所有安全事件是否有結構化 audit log、告警和使用者通知。

短一點可以說：

text
身份驗證安全不是只檢查 login API，
而是檢查註冊、登入、維持狀態、恢復、撤銷、稽核和高風險操作的完整生命週期。

二、 最低門檻總表 ​

如果只能先看一張表，先看這張。

面向最低門檻
密碼Argon2id / bcrypt / PBKDF2，不能明文、不能可逆加密
登入rate limit、一致錯誤訊息、記錄成功/失敗
Session隨機 session id、server-side revoke、安全 cookie
CookieHttpOnly、Secure、SameSite，HTTPS only
JWT短效 access token、refresh token rotation、可撤銷
忘記密碼token 短效、單次、存 hash、成功後撤銷 session
MFA高風險帳號/操作啟用，停用要重新驗證
OAuth/OIDC驗 state、nonce、issuer、audience、redirect URI
高風險操作step-up authentication，短效單用途 grant
後台強制 MFA、最小權限、admin audit log
Audit登入、失敗、MFA、權限、敏感操作都要記
告警MFA 停用、新增 admin、大量匯出、異常登入要告警

這張表不是完整要求，但如果其中一項做不到，身份系統就還不應該安心上線。

三、 帳號與註冊 ​

必檢項目 ​

  • [ ] Email / phone 是否有明確驗證流程。
  • [ ] 未驗證帳號是否限制敏感功能。
  • [ ] Email normalization 規則是否一致。
  • [ ] 是否保存原始 email 與 normalized email。
  • [ ] 是否避免不必要的帳號枚舉。
  • [ ] 註冊、重寄驗證信、OTP 是否有 rate limit。
  • [ ] Verification token 是否短效。
  • [ ] Verification token 是否單次使用。
  • [ ] Verification token 是否 DB 存 hash。
  • [ ] 長期未驗證帳號是否有清理策略。
  • [ ] 第三方登入首次註冊是否以 provider subject 識別。
  • [ ] Email 衝突時是否要求使用者登入既有帳號再綁定。
  • [ ] 邀請制 token 是否短效、單次、可撤銷。

常見風險 ​

錯誤：

text
註冊後 email 未驗證也給完整權限。

更好：

text
建立 pending account，只允許低風險 onboarding。

錯誤：

text
Google 回傳 email 相同就自動合併帳號。

更好：

text
以 provider + subject 綁定外部身份，email 衝突要重新驗證。

四、 密碼安全 ​

必檢項目 ​

  • [ ] 密碼是否絕不明文保存。
  • [ ] 密碼是否不是可逆加密保存。
  • [ ] 是否使用 Argon2id、bcrypt 或足夠強度的 PBKDF2。
  • [ ] 是否有 per-password salt。
  • [ ] 是否考慮 pepper，並放在 KMS / secret manager。
  • [ ] 是否保存 hash version / algorithm version。
  • [ ] 是否能 lazy rehash 升級舊 hash。
  • [ ] 密碼長度上限是否合理，避免 DoS。
  • [ ] 是否允許足夠長的密碼。
  • [ ] 是否避免過度複雜但無效的密碼規則。
  • [ ] 是否檢查常見弱密碼或外洩密碼。
  • [ ] 是否避免定期強制改密碼，除非有外洩或風險事件。

OWASP Authentication Cheat Sheet 建議重視強密碼、MFA 和安全恢復，而不是依賴定期強制改密碼。

常見風險 ​

錯誤：

text
sha256(password)

更好：

text
argon2id(password, salt, parameters)

錯誤：

text
AES.encrypt(password)

更好：

text
密碼只能驗證，不應能解密還原。

五、 登入流程 ​

必檢項目 ​

  • [ ] 登入 API 是否有 IP rate limit。
  • [ ] 是否有 account rate limit。
  • [ ] 是否有 IP + account rate limit。
  • [ ] 是否偵測 credential stuffing。
  • [ ] 是否偵測 password spraying。
  • [ ] 登入失敗訊息是否避免帳號枚舉。
  • [ ] 登入成功與失敗是否都記錄 audit log。
  • [ ] 多次失敗是否提高風險或要求額外驗證。
  • [ ] 登入成功後是否旋轉 session id。
  • [ ] 高風險登入是否要求 MFA。
  • [ ] 新裝置或新地點登入是否通知使用者。

錯誤訊息 ​

對外：

text
帳號或密碼錯誤。

內部 audit log 可以記：

text
user_exists=true
reason=invalid_password

不要對外說：

text
此 email 已註冊，但密碼錯誤。

除非產品已明確接受帳號枚舉風險。

必檢項目 ​

  • [ ] Session id 是否由 CSPRNG 產生。
  • [ ] Session id 是否有足夠 entropy。
  • [ ] Session id 是否不包含 user id、email、role 等可預測資訊。
  • [ ] DB 是否保存 session id hash，而不是原文。
  • [ ] 登入成功是否重新產生 session id，防 session fixation。
  • [ ] 登出是否撤銷 server-side session。
  • [ ] 修改密碼後是否撤銷其他 session。
  • [ ] 停用帳號後是否撤銷全部 session。
  • [ ] 是否支援查看與撤銷裝置。
  • [ ] 是否有 idle timeout。
  • [ ] 是否有 absolute timeout。
  • [ ] 是否依風險調整 session 長度。
  • [ ] 是否設定 HttpOnly。
  • [ ] 是否設定 Secure。
  • [ ] 是否設定 SameSite=Lax 或 SameSite=Strict。
  • [ ] 若 SameSite=None，是否一定搭配 Secure。
  • [ ] 是否強制 HTTPS。
  • [ ] 是否避免在 cookie 存敏感資料。
  • [ ] 是否考慮 __Host- cookie prefix。
  • [ ] 是否避免不必要的 Domain attribute。
  • [ ] Cookie scope 是否最小化。

OWASP Session Management Cheat Sheet 建議 session cookie 顯式設定安全屬性，並使用足夠隨機的 session id。HttpOnly 能降低 cookie 被 JavaScript 直接讀取，但不能完整防止 XSS 下的操作冒用；所以仍需要 XSS 防護、CSRF 防護和敏感操作重新驗證。

http
Set-Cookie: __Host-session=<opaque-random-id>; Path=/; HttpOnly; Secure; SameSite=Lax

後台或高敏感場景可考慮：

http
SameSite=Strict

但要看 SSO、支付跳轉、跨站流程是否會受影響。

七、 JWT 與 Token ​

必檢項目 ​

  • [ ] Access token 是否短效。
  • [ ] Refresh token 是否可撤銷。
  • [ ] Refresh token 是否 rotation。
  • [ ] 是否偵測 refresh token reuse。
  • [ ] Token 是否驗證 issuer。
  • [ ] Token 是否驗證 audience。
  • [ ] Token 是否驗證 signature。
  • [ ] Token 是否驗證 exp / nbf / iat。
  • [ ] 是否有 key rotation。
  • [ ] 是否避免在 JWT 放敏感資料。
  • [ ] 是否避免把長效 token 放 localStorage。
  • [ ] 登出是否讓 refresh token 失效。
  • [ ] 密碼變更是否撤銷 token family。

常見風險 ​

錯誤：

text
JWT 有簽名，所以不需要撤銷。

更好：

text
Access token 短效，refresh token 可撤銷與旋轉。

錯誤：

text
JWT payload 放完整個資和權限快照，永遠有效。

更好：

text
Token 只放必要 claims，敏感權限仍由後端檢查。

八、 忘記密碼與帳號恢復 ​

必檢項目 ​

  • [ ] 忘記密碼請求是否避免帳號枚舉。
  • [ ] Reset token 是否高隨機。
  • [ ] Reset token 是否短效。
  • [ ] Reset token 是否單次使用。
  • [ ] Reset token 是否 DB 存 hash。
  • [ ] Reset token 是否綁定 purpose。
  • [ ] Reset token 驗證是否有 rate limit。
  • [ ] Reset 頁是否避免 referrer 洩漏 token。
  • [ ] 重設成功後是否撤銷舊 session / refresh token。
  • [ ] 重設成功後是否通知使用者。
  • [ ] MFA 恢復是否不只依賴 email。
  • [ ] 高風險帳號恢復後是否暫時限制敏感操作。

OWASP Forgot Password Cheat Sheet 建議忘記密碼回應要避免枚舉，token 要足夠隨機、過期、單次使用，並防止 token 被暴力猜測或透過 referrer 洩漏。

常見風險 ​

錯誤：

text
Reset token 可以重複使用。

更好：

text
consume token 必須是原子操作，用過即失效。

錯誤：

text
密碼重設後舊裝置全部仍在線。

更好：

text
撤銷舊 session / refresh token，至少提供登出其他裝置。

九、 MFA / 2FA ​

必檢項目 ​

  • [ ] 是否支援 MFA。
  • [ ] 高權限或高風險帳號是否強制 MFA。
  • [ ] MFA 啟用前是否要求重新驗證。
  • [ ] MFA 啟用是否要求完成一次驗證才生效。
  • [ ] 是否產生 backup codes。
  • [ ] Backup codes 是否一次性使用。
  • [ ] Backup codes 是否 hash 保存。
  • [ ] 停用 MFA 是否要求重新驗證。
  • [ ] 停用 MFA 是否通知使用者。
  • [ ] MFA recovery 是否有安全流程。
  • [ ] 是否避免 SMS OTP 作為唯一高強度因素。
  • [ ] 是否支援抗釣魚因素，例如 Passkey / WebAuthn。

MFA 方法風險 ​

方法注意
SMS OTPSIM swap、攔截、號碼回收
Email OTP依賴 email 帳號安全
TOTP可被即時釣魚
Push要防 push fatigue
Passkey / WebAuthn抗釣魚較強，但要處理恢復與裝置遺失
Backup codes要安全保存、使用後失效

十、 OAuth / OIDC / 第三方登入 ​

必檢項目 ​

  • [ ] 使用 Authorization Code Flow。
  • [ ] SPA / Mobile 是否使用 PKCE。
  • [ ] 是否驗證 state 防 CSRF。
  • [ ] OIDC 是否驗證 nonce 防 replay。
  • [ ] 是否驗證 issuer。
  • [ ] 是否驗證 audience / client id。
  • [ ] 是否驗證 token signature。
  • [ ] 是否驗證 exp / iat。
  • [ ] redirect URI 是否嚴格白名單。
  • [ ] 不使用 implicit flow 作為新設計。
  • [ ] 不信任前端直接傳來的 profile。
  • [ ] 第三方帳號是否用 provider + subject 綁定。
  • [ ] email 衝突是否要求重新驗證再合併。
  • [ ] 解除綁定後是否仍保留至少一種登入方式。

常見風險 ​

錯誤：

text
前端拿到 Google profile 後傳 email 給後端，後端直接登入。

更好：

text
後端完成 code exchange，驗證 id token，再使用 provider subject 綁定帳號。

十一、 高風險操作重新驗證 ​

必檢項目 ​

  • [ ] 修改密碼是否要求 recent auth。
  • [ ] 修改 Email / phone 是否要求重新驗證。
  • [ ] 停用 MFA 是否要求強重新驗證。
  • [ ] 新增 Passkey 是否要求重新驗證。
  • [ ] 新增收款帳號是否要求重新驗證。
  • [ ] 大額交易是否要求 step-up / 交易簽章。
  • [ ] 匯出資料是否要求 step-up。
  • [ ] 查看完整敏感資料是否要求重新驗證或填寫目的。
  • [ ] Step-up grant 是否短效。
  • [ ] Step-up grant 是否單用途。
  • [ ] Step-up grant 是否綁定 user / session / purpose。
  • [ ] Step-up grant 是否可單次使用。

常見風險 ​

錯誤：

text
使用者已登入，所以可以直接停用 MFA。

更好：

text
停用 MFA 前要求強重新驗證，並通知使用者。

十二、 授權與權限 ​

必檢項目 ​

  • [ ] 是否分清 Authentication 和 Authorization。
  • [ ] 每個後端 API 是否檢查權限。
  • [ ] 是否避免只靠前端隱藏按鈕。
  • [ ] 是否有 resource ownership 檢查。
  • [ ] 是否支援 tenant / organization scope。
  • [ ] 是否有最小權限設計。
  • [ ] 後台是否使用 RBAC / permission。
  • [ ] 權限變更是否需要 audit log。
  • [ ] 權限提升是否需要重新驗證。
  • [ ] 是否防止 IDOR。

範例 ​

錯誤：

text
GET /invoices/:id
只檢查使用者已登入。

更好：

text
檢查 invoice.user_id 是否等於 session.user_id，或使用者是否有該 tenant 權限。

十三、 CSRF / XSS / 前端儲存 ​

必檢項目 ​

  • [ ] Cookie-based session 是否有 CSRF 防護。
  • [ ] 是否設定 SameSite。
  • [ ] 高風險 mutation API 是否檢查 CSRF token 或同等防護。
  • [ ] 是否有 XSS 防護。
  • [ ] 是否避免長效 token 放 localStorage。
  • [ ] 前端是否不保存敏感 claims。
  • [ ] SSR hydration 是否避免把 token 注入 HTML。
  • [ ] logout 是否清理前端狀態。
  • [ ] Token refresh 是否處理 race condition。

注意：

text
HttpOnly cookie 能降低 token 被 JS 讀走，
但不能阻止 XSS 在使用者瀏覽器裡發送已登入請求。

所以敏感操作仍要 step-up、CSRF 防護和後端權限檢查。

十四、 Audit Log ​

必檢項目 ​

  • [ ] 登入成功是否記錄。
  • [ ] 登入失敗是否記錄。
  • [ ] MFA 成功/失敗是否記錄。
  • [ ] 密碼修改是否記錄。
  • [ ] 忘記密碼是否記錄。
  • [ ] Session 撤銷是否記錄。
  • [ ] 第三方登入綁定/解除是否記錄。
  • [ ] 權限變更是否記錄。
  • [ ] 高風險操作是否記錄。
  • [ ] 管理員操作是否記錄。
  • [ ] 是否有 actor / target / action / result。
  • [ ] 是否有 request id / correlation id。
  • [ ] Log 是否不包含密碼、OTP、token。
  • [ ] Audit log 是否有存取控制。
  • [ ] 查詢或匯出 audit log 是否也記錄。
  • [ ] 高風險事件是否告警。

高風險告警 ​

  • [ ] MFA 停用。
  • [ ] 新增管理員。
  • [ ] 權限提升。
  • [ ] 大量登入失敗。
  • [ ] 多帳號同來源失敗。
  • [ ] 大量資料匯出。
  • [ ] Break-glass account 使用。
  • [ ] Audit writer 停止。

十五、 後台管理員 ​

必檢項目 ​

  • [ ] 後台是否使用獨立 admin session。
  • [ ] 管理員是否強制 MFA。
  • [ ] 是否優先支援 Passkey / WebAuthn / 硬體金鑰。
  • [ ] 是否避免共用管理員帳號。
  • [ ] 是否有最小權限角色。
  • [ ] 是否限制 super admin 數量。
  • [ ] 是否有 IP allowlist / VPN，依場景。
  • [ ] 是否有新裝置或新地點告警。
  • [ ] 管理員 session 是否較短效。
  • [ ] 敏感管理操作是否要求 step-up。
  • [ ] Impersonation 是否記錄 actor 和 target。
  • [ ] Break-glass account 是否受嚴格監控。
  • [ ] 離職員工帳號是否能即時停用。

十六、 金融 / 醫療 / 高敏感場景 ​

必檢項目 ​

  • [ ] 是否依操作風險分層。
  • [ ] 查看敏感資料是否需要 recent auth。
  • [ ] 匯出資料是否要求重新驗證。
  • [ ] 大額交易是否需要交易簽章。
  • [ ] 醫療授權是否綁定授權範圍與期限。
  • [ ] 是否做資料遮蔽。
  • [ ] 後端是否回傳最小必要資料。
  • [ ] 是否記錄敏感資料查看 audit log。
  • [ ] 是否偵測大量查詢或匯出。
  • [ ] 是否處理代理人、照護關係、tenant scope。
  • [ ] 帳號恢復後是否限制高風險操作。
  • [ ] 是否和法務/資安/合規確認保存與通知要求。

十七、 營運與事件應變 ​

必檢項目 ​

  • [ ] 是否有安全通知模板。
  • [ ] 是否有帳號凍結流程。
  • [ ] 是否有撤銷所有 session 的能力。
  • [ ] 是否有撤銷 refresh token family 的能力。
  • [ ] 是否有 forced password reset 能力。
  • [ ] 是否有 MFA reset 審核流程。
  • [ ] 是否有安全事件 runbook。
  • [ ] 是否能查某 user 的所有 session。
  • [ ] 是否能查某 IP 的所有登入嘗試。
  • [ ] 是否能查某管理員的所有操作。
  • [ ] 是否能快速停用某 OAuth provider 或 IdP。
  • [ ] 是否定期演練 break-glass / account recovery。

身份系統上線後不是就結束。

它需要長期營運能力。

十八、 測試清單 ​

自動化測試 ​

  • [ ] 密碼 hash 測試。
  • [ ] 登入成功/失敗測試。
  • [ ] rate limit 測試。
  • [ ] session revoke 測試。
  • [ ] logout all 測試。
  • [ ] password reset token 單次使用測試。
  • [ ] verification token 過期測試。
  • [ ] MFA 啟用/停用測試。
  • [ ] step-up grant purpose 測試。
  • [ ] 權限拒絕測試。
  • [ ] audit log 產生測試。

安全測試 ​

  • [ ] 帳號枚舉測試。
  • [ ] CSRF 測試。
  • [ ] XSS 影響面測試。
  • [ ] IDOR 測試。
  • [ ] session fixation 測試。
  • [ ] token replay 測試。
  • [ ] refresh token reuse 測試。
  • [ ] OAuth state / nonce 測試。
  • [ ] redirect URI bypass 測試。
  • [ ] rate limit bypass 測試。

OWASP Web Security Testing Guide 可以作為實際測試參考，尤其 session management、authentication、authorization 相關章節。

十九、 面試回答模板 ​

如果面試官問：

你會怎麼檢查登入系統安全？

可以這樣答：

我會從身份生命週期檢查，而不是只看 login API。第一是帳號建立與驗證，確認 email/phone verification token 短效、單次、存 hash，且避免帳號枚舉。第二是密碼儲存，使用 Argon2id 或 bcrypt 加 salt，不可明文或可逆加密。第三是登入與 session，登入要 rate limit、記錄成功失敗，session id 要高隨機，cookie 設 HttpOnly、Secure、SameSite，登出和修改密碼要能撤銷 session。第四是 token 和 MFA，access token 要短效，refresh token 要旋轉與可撤銷，MFA 啟用、停用和恢復都要有安全流程。第五是高風險操作，修改安全設定、匯出資料、大額交易要重新驗證或簽章。最後是 audit log 和告警，所有身份、權限與敏感操作都要結構化記錄，不能記密碼或 token，高風險事件要即時告警。

二十、 常見錯誤 ​

1. 只檢查登入成功 ​

錯誤：

text
帳密對就發 token。

正確：

text
還要檢查 rate limit、風險、MFA、session、audit、通知。

2. 做了 JWT 就以為無狀態萬能 ​

錯誤：

text
JWT 不用存 server，所以登出前端刪掉即可。

正確：

text
長效 refresh token 仍要可撤銷，access token 要短效。

3. 忘記密碼比登入還弱 ​

錯誤：

text
登入有 MFA，但忘記密碼只靠 email 就能完全接管。

正確：

text
高風險帳號恢復要額外身份確認，恢復後限制敏感操作。

4. Audit log 成為新漏洞 ​

錯誤：

text
Log 裡有 password、OTP、token、完整病歷。

正確：

text
Log 只記必要安全事件和識別碼，敏感秘密絕不進 log。

5. 後台沿用前台安全等級 ​

錯誤：

text
role=admin 就能進後台。

正確：

text
後台獨立 session、強制 MFA、最小權限、敏感操作 step-up、完整 audit。

總結 ​

身份驗證安全檢查清單可以濃縮成九句話：

  1. 密碼不能明文或可逆保存。
  2. 登入要防暴力破解與帳號枚舉。
  3. Session 要安全、短效、可撤銷。
  4. Cookie 要設 HttpOnly、Secure、SameSite。
  5. Token 要短效、可輪替、可撤銷。
  6. 忘記密碼和帳號恢復不能比登入更弱。
  7. MFA 要包含啟用、停用、恢復與 backup codes。
  8. 高風險操作要重新驗證，交易/文件要簽章。
  9. 所有身份與敏感操作都要 audit log 和告警。

一句完整的面試回答可以是：

身份驗證安全要檢查完整生命週期。帳號註冊要驗證 email/phone、避免枚舉；密碼要用 Argon2id 或 bcrypt 加 salt 儲存；登入要有 rate limit、credential stuffing 防護、一致錯誤訊息和 audit log；Web session 要用高隨機 server-side session id，cookie 設 HttpOnly、Secure、SameSite，並支援登出、撤銷和 timeout；JWT 要短效，refresh token 要 rotation 和可撤銷；忘記密碼 token 要短效、單次、存 hash；MFA 要有啟用、停用、恢復和 backup codes；OAuth/OIDC 要驗 state、nonce、issuer、audience、redirect URI；修改密碼、停用 MFA、匯出資料、大額交易等高風險操作要重新驗證或簽章；後台要強制 MFA、最小權限和完整 audit log；所有安全事件要結構化記錄並對高風險事件告警。

延伸閱讀 ​