繁體中文（香港）
  • security
  • identity
  • checklist
  • auth

用戶身份的基本安全檢查清單

建立用戶身份是任何應用程序的關鍵組成部分。驗証用戶名和密碼可能看似最簡單的方法，但還有許多其他方面需要考慮。

Gao
Gao
Founder

Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
Get started
Product screenshot

介紹

建立用戶身份是任何應用程序的關鍵組成部分。它能讓你提供個人化的體驗、提升數據質素和改善用戶留存率。

驗証用戶名和密碼可能看似最簡單的方法，但還有許多其他方面需要考慮。我們開始吧！

基礎設施

強制使用 HTTPS

讓我們從基本的開始。總是強制使用 HTTPS（超文本傳輸安全協定）來加密互聯網上的數據傳輸。HTTPS 確保用戶設備和你的伺服器之間交換的數據保持機密和防篡改。

設置 HTTPS 可能看起來很有挑戰性，但有很多工具和服務可以幫助你：

  • 如果你是自我托管， Let's Encrypt 提供免費的 SSL/TLS 證書，可以用於在你的網站上啟用 HTTPS。
  • 如果你使用雲端供應商，例如 AWS、Azure 或 Google Cloud，你可以使用他們的托管服務來設置 HTTPS。

不允許公開數據庫訪問，僅限於信任來源

雖然這也可能看似基本，但由於允許公開訪問數據庫，已發生很多安全漏洞。因此，這裡值得一提。

始終記得絕不要允許公開訪問你的數據庫。將數據庫放在私人網絡中，只允許信任來源訪問。

安全管理私密令牌

私密令牌，例如訪問令牌或 API 密鑰，通常用於程序式身份驗證和授權目的。為了安全地管理這些令牌：

  • 使用短效令牌和刷新令牌來減少未經授權訪問的風險。
  • 使用安全令牌存儲機制，例如密鑰庫，來保護令牌免受未經授權的訪問。
  • 定期旋轉令牌以防止其被洩露。一些協議，例如 OAuth 2.0，提供令牌輪換的機制。
  • 保持對令牌撤銷的控制，以防發生安全漏洞。

明智地選擇密碼哈希算法

如果你有密碼哈希的經驗，你可能知道有很多個算法可用，其中一些不再被認為是安全的，如 MD5、SHA-1 和 SHA-2。

它們不安全的常見原因有：

  • 它們不是專門為密碼哈希設計的，其計算速度太快，使得暴力破解攻擊更容易。
  • 它們缺乏鹽的使用，使得為它們創建 彩虹表 更容易。
  • 它們易受碰撞攻擊，使得攻擊者可以生成具有相同哈希值的不同密碼。

行業標準的密碼哈希算法，如 bcrypt 和 Argon2，已被設計用來解決這些問題。由於這篇文章的範圍有限，我們不會詳細討論它們。更多資訊可查看密碼哈希的演變。

學習並嚴格遵循開放標準

開放標準如 OAuth 2.0 和 OpenID Connect (OIDC) 提供安全和標準化的用戶身份驗證和授權方法。它們已經過實戰測試並被業界廣泛採用。

然而，錯誤地實施它們可能導致安全漏洞，即使是有經驗的開發團隊也是如此。一個最近的例子是 在 Expo 中發現的 OAuth 漏洞，一個用於建立移動應用程序的流行框架。它是一個小錯誤可能導致安全漏洞的好例子。

靜態數據加密

靜態數據，如存儲的用戶信息或數據庫備份，應使用強大的加密算法加密。這確保即使數據被攔截，也不能在沒有解密密鑰的情況下閱讀。仔細檢查你的雲供應商是否支持此功能，因為合規常常要求這樣做。

設置防火牆

DDoS（分佈式拒絕服務）攻擊雖然是古老的，但仍然是個重要的威脅。根據 Cloudflare 2022年第4季度的DDoS威脅報告，HTTP DDoS 攻擊流量同比增加了 79%。與其建立自己的解決方案，不如設置托管防火牆並利用通知工具來減輕這一風險。

應用程序和客戶端

提高公共客戶端的安全級別

公共客戶端，如移動應用程序或單頁面應用程序，更容易受到安全漏洞的侵害。即使你提供它們，你也應在安全模型中將它們視為不受信任的來源。例如：

永遠不信任公共輸入數據

用戶輸入往往是安全漏洞的重要來源，常被忽視。一些常見而被忽視的漏洞類型包括 跨站腳本 (XSS) 和 SQL 注入。必須在使用之前對所有用戶輸入數據進行驗證和清理。

追蹤活動

保持用戶活動的審計跟蹤有助於檢測和調查安全事件。記錄並監控用戶行為，如登錄嘗試、密碼更改或敏感操作。分析這些日誌可以提供潛在安全漏洞或可疑活動的有價值見解。

實施可靠的身份驗證

實施強大的身份驗證機制來驗證用戶身份。如之前所述，考慮使用安全協議如 OAuth 2.0 或 OpenID Connect 進行身份驗證。更多資訊可以參考CIAM 101：身份驗證、身份、SSO。

建立可靠的授權（例如，實施基於角色的訪問控制）

除身份驗證外，必須具備適當的授權機制。實施基於角色的訪問控制 (RBAC) 以確保用戶僅能訪問其被授權執行的資源和操作。更多資訊可以參考CIAM 102：授權和基於角色的訪問控制。

實施多重身份驗證 (MFA)

多重身份驗證 (MFA) 增加了一層安全性，要求用戶提供一個或多個識別形式，例如密碼和發送到移動設備的一次性代碼。MFA 的另一個好例子是 GitHub 要求用戶在執行敏感操作如刪除存儲庫時輸入從其移動應用程序獲取的一次性代碼，這在網頁上顯示。

然而，對於大多數早期的初創企業來說，MFA 並不是必需的，尤其是當你沒有現成的解決方案時。這可能過於繁瑣並對用戶體驗有負面影響。

文化

上述建議主要涵蓋 "被動" 的安全措施，它們是在發生安全事件之前已知的。然而，也有 "主動" 的安全措施可以用來改善整體的安全態勢，從長遠來看更有效。

教育你的團隊和用戶關於網絡釣魚和社會工程

網絡釣魚攻擊和社會工程是關鍵的，因為它們可以使上面提到的許多安全措施失效。例如，如果用戶被騙交出了密碼或點擊了一個看似無害但包含惡意程式的貓咪圖片，那麼你強力的密碼哈希算法或防火牆規則變得毫無意義。

大多數人覺得安全培訓很無聊，通常確實如此。因此，改變你教育團隊和用戶的方式吧。例如，你可以在真正的攻擊者這樣做之前發送一封模擬的網絡釣魚郵件，並展示如何識別它。你甚至可以提供報告郵件給安全團隊的獎勵。

設置 DevSecOps

除了手動安全審查外，你還可以實施 DevSecOps 實踐以自動化安全檢查。例如，你可以設置 CI/CD 管道來運行靜態代碼分析工具如 CodeQL 並自動運行使用工具如 OWASP ZAP 的滲透測試。

接受最嚴格的配置而不影響用戶體驗

在涉及安全時，總是選擇最安全的配置，而不影響用戶體驗。避免走捷徑或為了方便而妥協安全。安全應始終是首要任務。

作為初創企業或獨立開發者，你可能覺得自己缺乏必要的資源來實施這些措施。然而，市面上有提供免費或對初創企業友好的專業安全服務。花時間審查並考慮使用它們。

結論

安全是一個複雜的話題，不可能在一篇文章中涵蓋所有內容。我們希望這篇文章可以幫助你或你的團隊建立更強的安全意識。如果你正在構建新應用程序，你也可能想查看 Logto，這是一個幫助你以最小努力開發、管理和保護產品用戶身份的平台。

今天就試試 Logto