OWASP : Authentication Cheat Sheet 中文譯本

資料來源
https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

簡介

認證（AuthN是驗證個人、實體或網站的身份，確認其是否是其聲稱的對象，這個過程通過檢查一個或多個認證方式的有效性來進行（如密碼、指紋或安全令牌）。

數位身份 是在線交易中對某個對象的唯一表示。數位身份在數位服務中始終是唯一的，但不一定需要與真實世界中的具體個人相關聯。

身份證明 是確立某個主體實際是其所聲稱的個人，這個概念與KYC（了解您的客戶）有關，旨在將數位身份與真實個人綁定。

會話管理 是伺服器維持與其交互的實體狀態的過程。伺服器通過會話識別碼來記住在整個交易過程中如何應對後續請求。會話應該對每個使用者唯一，且計算上非常難以預測。詳細做法可參考「會話管理速查表」。

認證的一般指南

使用者ID

使用者ID的主要功能是唯一標識系統中的使用者。理想情況下，應隨機生成使用者ID，以防止創建可預測或連續的ID，這可能會構成安全風險，特別是在使用者ID可能被外部推斷或公開的系統中。

使用者名稱

使用者名稱是使用者選擇的、易於記憶的標識符，登入系統時使用。使用者ID和使用者名稱有時可以互換使用，尤其是當使用者名稱同時作為系統中的唯一標識符時。

允許使用者使用其電子郵件地址作為使用者名稱，但必須在註冊時驗證該電子郵件地址。此外，應提供選擇非電子郵件地址作為使用者名稱的選項。

認證解決方案與敏感帳戶

不要允許 使用敏感帳戶（例如後端/中介層/資料庫內部使用的帳戶）登入前端用戶界面。
不要使用 與內部系統相同的認證解決方案（如 IDP/AD）處理不安全的訪問（如公開訪問/DMZ區域）。

實施適當的密碼強度控制

當使用密碼進行認證時，密碼強度是一個關鍵問題。一個「強」密碼策略應使得通過手動或自動方式猜測密碼變得非常困難。以下是強密碼的特徵：

• 密碼長度：應強制執行密碼的最小長度。根據NIST SP800-63B，長度少於8個字符的密碼被認為是弱的。
• 最大密碼長度 至少應為64個字符，允許使用通過短語作為密碼。
• 不應 隱式截斷密碼。
• 允許使用所有字符，包括 Unicode 和空格。
• 當發生密碼洩漏或識別到安全漏洞時，應進行密碼輪替。
• 實施安全的密碼恢復機制
  應提供一個機制，讓使用者能夠在忘記密碼的情況下重新獲取對其帳戶的訪問權。詳細資訊請參閱「忘記密碼速查表」。

安全存儲密碼

應用程序必須使用正確的密碼學技術來存儲密碼。具體做法可參閱「密碼存儲速查表」。

比較密碼哈希值時使用安全函數

在可能的情況下，應使用語言或框架提供的安全密碼比較函數進行哈希值比較 ，例如PHP中的password_verify()函數。

更改密碼功能

在開發更改密碼功能時，應確保：

• 使用者具有活動會話並進行身份驗證。
• 驗證當前密碼以確保是合法使用者在進行更改操作。

只通過TLS傳輸密碼

所有登錄頁面和認證後的頁面都必須僅使用TLS（傳輸層安全協議）或其他強加密傳輸技術訪問，以防止使用者憑證被攔截或會話ID洩漏。

敏感操作需要重新認證

為了防止跨站請求偽造（CSRF）和會話劫持，當更新敏感帳戶信息或執行敏感交易時，應要求使用者重新輸入其當前憑證。

考慮使用強交易認證

對於某些應用，應使用第二因素來確認使用者是否可以執行敏感操作。具體做法可參閱「交易授權速查表」。

避免身份驗證錯誤消息洩漏信息

為防止使用者ID和密碼枚舉，應以通用方式回應身份驗證錯誤，例如「無效的使用者ID或密碼」，而不是具體說明是哪個字段不正確。

防止自動化攻擊

應實施適當的防禦機制以抵禦自動化攻擊，如暴力破解、憑證填充（使用其他站點洩漏的使用者名/密碼進行測試）等。可採用措施包括：

• 多因素認證 (MFA)：這是防止大多數密碼相關攻擊的最有效防禦措施。
• 登入節流：限制使用者多次嘗試登入的次數。
• 帳戶鎖定：多次登入失敗後鎖定帳戶，防止暴力破解攻擊。

使用不需要密碼的認證協議

在某些情況下，可能需要使用無需密碼的認證協議，例如OAuth、OpenID或SAML，這些協議提供了在不暴露使用者密碼的情況下，進行安全認證的方式。

OAuth、OpenID與SAML
這些是常用的身份驗證和授權協議，提供單點登入 (SSO) 等功能。OAuth適用於無需密碼的API訪問，OpenID適合用於公開網站的單點登入，而SAML則多用於企業內部應用。

FIDO（快速身份聯盟）
FIDO提供了兩種協議：UAF（無密碼認證）和U2F（增加第二因素，這些協議基於公鑰密碼學挑戰應答模型，可增強身份驗證的安全性。

密碼管理器

應用程序應支持標準HTML表單，避免使用Flash或Silverlight等插件，並允許使用者貼上密碼以便於使用密碼管理器。

更改使用者註冊電子郵件地址

使用者的電子郵件地址經常會發生變更。以下是系統處理此類情況的推薦流程：

注意：如果啟用了多因素認證 (MFA)，此過程會較不嚴格，因為身份驗證的證明比僅依賴密碼更強。

如果使用者啟用了多因素認證 (MFA) 的推薦流程：

1. 確認使用者的身份驗證 Cookie/令牌是否有效。如果無效，顯示登入頁面。

2. 向使用者描述更改註冊電子郵件地址的過程

3. 要求使用者提交擬更改的新電子郵件地址，並確保其符合系統規則。

4. 要求使用者進行多因素認證來驗證身份。

5. 將新的電子郵件地址存儲為待處理變更。

6. 創建並存儲兩個有時間限制的 nonce：
   一個用於通知系統管理員， 另一個用於使用者確認。 向當前的電子郵件地址和新的電子郵件地址發送兩封包含這些 nonce 的電子郵件：

• 通知當前地址
  的電子郵件，告知使用者即將進行更改，並提供一個鏈接，以防更改發生意外情況。
• 確認新地址
  的電子郵件，要求使用者確認更改，並提供鏈接以處理意外情況。 根據鏈接的響應處理後續操作。

如果使用者未啟用多因素認證的推薦流程

1. 確認使用者的身份驗證 Cookie/令牌是否有效。如果無效，顯示登入頁面。

2. 向使用者描述更改註冊電子郵件地址的過程。

3. 要求使用者提交擬更改的新電子郵件地址，並確保其符合系統規則。

4. 要求使用者輸入當前密碼以驗證身份。

5. 將新的電子郵件地址存儲為待處理變更。

6. 創建並存儲三個有時間限制的 nonce，分別用於：

• 系統管理員通知，
• 使用者確認，
• 以及密碼驗證的額外步驟。

7. 向當前的電子郵件地址和新的電子郵件地址發送兩封電子郵件，包含這些 nonce：

• 確認當前地址 的電子郵件，要求使用者確認更改，並提供鏈接以處理意外情況。
• 確認新地址 的電子郵件，要求使用者確認更改，並提供鏈接以處理意外情況。

8. 根據鏈接的響應處理後續操作。