Web 應用程式身分驗證，你該注意什麼？

由於 web 應用程式相比起安裝在電腦上的軟件有更多的優勢，導致 web 應用程式如雨後春筍般出現。使用者可以在不須要把軟件安裝在電腦的情況下，便能輕而易舉地使用程式。然而，由於大量訊息會在用戶的裝置和 web 應用程式的服務器間傳送，如何保護好使用者資訊也成為開發 web 應用程式的一大課題。

為了確保你的應用程式能夠更安全地保護好使用者資料，我們列出了幾點開發 web 應用程式時和登入安全有關的重點。

保護 Web 應用程式身分驗證過程的基礎知識

當使用者嘗試登入時 使用統一的登錄失敗訊息

無論用家是輸入錯的使用者名稱或密碼也好，系統須要即時傳送一個統一的登入失敗告示。如果系統分別顯示出「無效用戶」或「錯誤密碼」訊息，駭客可以猜測到用戶名是否存在。從那個步驟開始，他們可以開始猜測特定帳戶的密碼，並試圖登入該帳戶。

使用HTTPS 安全協定

傳輸層安全性協定（Security Sockets Layer，SSL）是一種允許在客戶和網路系統之間進行加密通訊的協議。沒有 SSL 證書的網站和 web 應用程式就像沒有食物安全檢查員允許經營的餐館一樣。使用者仍然可以使用這些網絡服務，不過使用這些服務有一定程度上的資安風險。

一旦你的網站或 web 應用程式安裝並配置了 SSL 證書，它就可以使用 HTTPS 安全協定來確保在瀏覽器和伺服器之間傳遞的任何用戶私人信息（例如登錄信息、付款等）都是經過加密的。在沒有 HTTPS 安全協定的情況下，駭客可以輕鬆地在數據傳輸過程中竊聽和查看資訊。

慢慢地把密碼進行雜湊處理

安全存儲敏感的用戶信息至關重要，因為不慎把數據外洩，可能會有可怕的資安問題。一般而言，我們都不建議網站開發人員以純文字形式保存用戶的密碼，因為駭客一旦侵入您的數據庫，就可以毫不費力地獲取用戶的所有身分驗證資訊。

開發人員可以透過一種叫做雜湊函數的單向函數來更安全地儲存用戶的密碼，即是通過複雜的數學演算法將密碼轉換為另一種形式。這與直接加密不同，因為經過雜湊的密碼（hashing）無法轉換回其原始純文本形式。運用在保護密碼上的雜湊函數運行速度需要比較慢，這樣才會增加攻擊者破解密碼所需要的時間。

雖然不少人仍然會使用 MD5 或 SHA-1 來保護密碼，但這些演算法在被設計時並不是以保護密碼為目標。它們的運作非常快速，這讓駭客很容易使用蠻力破解 (brute-force attack) 猜到密碼。此外，開發人員們也在這些演算法裡發現了一些漏洞，因此通常不推薦使用 MD5 和 SHA-1。

OWASP 推薦數種 password hashing algorithms，例如 Argon2, scrypt, bcrypt 和 PBKDF2，它們都是專門設計為保護密碼所用。

在雜湊處理前把密碼「加鹽」複雜化

只是對密碼進行雜湊處理是不足夠的，因為還有幾個方法，例如字典攻擊（dictionary attack）和蠻力攻擊（brute-force attack），這些都能讓駭客成功解鎖密碼。要讓密碼更安全，你需要為密碼「加鹽」，即是在進行雜湊處理前添加額外的一連串字符串。「加鹽」很重要，因為駭客需要更多電腦運算能力去破解這種加鹽並且經過雜湊處理的密碼。上面提到的幾種password hashing algorithms 都內建有「加鹽」的設計。

設定多重要素驗證

現今不少科技領頭會要求自家員工以及使用者進行多重要素驗證並不是毫無根據的，光靠傳統的純密碼驗證已經無法抵禦駭客的攻擊。在2013年，Deloitte 聲稱超過90%用戶自行生成的密碼會輕易遭受到駭客的攻擊，也因此只有單一層的密碼保護的風險十分高，完全無法保護用戶的各種敏感信息。

為了能更安全地保護使用者，Web應用程式通常會實施多重要素驗證（MFA）。大多數情況下，會要求至少透過兩個因素來對用戶進行身份驗證（這也稱為雙因素身份驗證或 2FA）。因為這些替代的方法比較難被駭客所模仿，一些無須密碼的身分驗證方法，例如指紋掃描、臉部辨識、發送到WhatsApp 或 Telegram 的一次性密碼（one-time password）等，都已經被納入在身分驗證過程當中。

將敏感信息與常規數據分開保存

有時候，web 應用程式的開發者可能會儲存所有用家的資訊在同一個表格中，例如id、用戶名稱、密碼、姓名、電郵、上一次登入時間等等。實作上這樣的操作或許合理，但當你嘗試為不同的用戶授予不同的訪問權限時，而你又只想獲取一些非機密資訊時，這樣的儲存方式反而會造成不少麻煩。

例如開發人員在查詢數據時，只須要輸入 SELECT * FROM users_info 便能獲取數據，但這將會暴露一些敏感數據。要避免這個問題，可以把機密訊息儲存在分開的列表中，甚至將它放入另一個數據庫以獲得更好的保護。

保護身份驗證時很易忘記的幾個步驟

妥善地選擇和設置雜湊演算法

我們提到密碼不能以純文字形式儲存下來，但是，正確地雜湊處理密碼也不是一件易事。

其中一種常見錯誤是，例如密碼演算法「bcrypt」是一種常見的選擇。這是一個不錯的選項，但你必須記住最大長度限制為72個位元組（32個unicode字符）。如果你在應用程式中使用 bcrypt，你應該要限制字元輸入數目，而不是在後端偷偷地截斷密碼。

目前最好的密碼雜湊演算法是 Argon2 (Argon2id 的變體) ，因為它提供了一種比較平衡的方法來防止旁路攻擊和 GPU-based 攻擊。這裡可以配置三個不同的參數，即最小內存大小（m）、最小迭代次數（t）和並行度（p）。​​透過在系統上測試不同的參數，可以讓雜湊處理所需的時間只介於 500 毫秒到 1 秒之間，才能在用戶體驗和資安之間取得平衡。

如果使用 JWT token，請根據用戶ID進行反向驗證

雖然許多人不推薦使用 JWT tokens 作為身分驗證的tokens，但仍然有很多原因令人們繼續使用它；使用 JWT tokens 時必須要注意一些讓駭客能繞過驗證的安全漏洞。為確保服務器使用正確的密碼和算法來驗證 tokens ，應該選擇使用 JWK（JSON 網絡密鑰）和“kid”（密鑰 ID）標頭。服務器可以隨時利用 JWT Tokens 中的密鑰 ID來尋找檢查密鑰密碼和演算。

確認沒有被寫死的秘密密碼或是後台

當公司團隊慢慢壯大，或系統中的程式變得更為複雜時，開發人員更容易在寫程式時因一時疏忽，把系統中的某些秘密密碼鎖死／寫死（hard-coded）。

當我們在幫客戶檢察系統或代碼時，另一個常見問題是身分驗證系統會故意留下「後門」，無論是出於易於偵錯或使用者接受度測試即驗收測試（UAT）的原因，例如在 HTTP 標頭中設置特殊值時授予超級權限。

這是一個嚴重的問題，因為一旦攻擊者可以接觸到你的源代碼（source code)，整個安全系統會立刻受到威脅。

沒有登錄紀錄

如果有詳細記錄登入和登入失敗的審計日誌 (audit log) ，對於追蹤駭客並且進一步阻止他們的攻擊是非常有用的，同時審計日誌也是找出系統中的漏洞時非常重要的工具。

在SSO中只依賴客戶端的資料做登入行動

我們看到的另一個常見問題是，通過社交平台 OAuth 2.0 的身份驗證完全在客戶端處理，然後依賴客戶端報告用戶 ID 而無需進一步身分驗證。這會帶來嚴重的風險。

生成具有加密強源的隨機密碼數字

電腦計算機會使用種子值生成隨機數字。如果種子值已知，則可以再現隨機序列。這些算法稱為偽隨機數生成器 (PRNG)。 PRNG 有兩種類型，統計型和加密型。統計型 PRNG 在統計應用中很有用；而當安全性取決於不可預測值時，應使用加密 PRNG。

例如，為了在一段時間內保持活躍的收據創建一個隨機的網址。至為關鍵的是，你必須要確保網站的順序不能輕易地被駭客猜出來；否則，攻擊者很易便會猜出具有效收據的網址。

這兩種演算法通常可以在不同的編程語言中找到。例如，Java 為統計型PRNG 提供“Random.nextInt()”或為加密型PRNG 提供“SecureRandom”。

將您的 Web 應用程序與 Authgear 整合以實現更安全的身份驗證

由於駭客不斷地在尋找新的方法來竊取用戶的機密資料，開發業者們已經不能夠再輕視使用者的安全。為了跟上他們的步伐，開發人員必須主動採取新的研究和嘗試。

Authgear 能夠提供安全地身份驗證機制來保護你的 Web 應用程式，以便你的工程團隊能夠專注於開發核心系統功能。我們不僅會為您解決上述安全問題，還會幫助你提供更好的認證體驗，同時降低營運成本。

立即聯繫我們來了解如何讓你的 web 應用程式更安全，以及 Authgear 能夠提供怎樣的協助讓你增加更多的使用者。