密碼安全的認知落差：為什麼「複雜度」不是唯一解
在數位生活的日常中，我們經常被提醒要設定「高強度密碼」，包含大小寫、符號與數字的組合。然而，這種觀念往往將安全責任過度集中在用戶的記憶能力上，卻忽略了駭客攻擊的底層邏輯。事實上，大多數的密碼外洩並非因為密碼不夠複雜，而是因為系統儲存密碼的方式存在嚴重缺陷，或是傳輸路徑缺乏適當的加密防護。
許多使用者誤以為只要將密碼設定得越長，安全性就越高。這種迷思忽略了所謂的「撞庫攻擊（Credential Stuffing）」與「暴力破解」之間的本質差異。若後端系統未妥善實作加鹽（Salting）與適當的雜湊演算法，無論密碼多麼複雜，在資料庫外洩的瞬間，這些明文或弱加密的密碼資訊便會直接暴露在駭客的彩虹表（Rainbow Table）攻擊之下。
雜湊與加密的應用邊界：別再搞混兩者的功能
在資安架構中，雜湊（Hashing）與加密（Encryption）是兩種完全不同的技術手段。雜湊是一種「單向轉換」，將任意長度的輸入轉換成固定長度的字串，其設計初衷是為了驗證資料完整性，而非為了還原資料。反之，加密則是「雙向轉換」，必須具備相對應的密鑰才能將資料還原為明文。許多初學者在架構系統時，常誤將密碼「加密」儲存，這反而埋下了更大的隱憂。
雜湊演算法的選型邏輯
在選擇雜湊演算法時，我們必須區分「快速雜湊」與「慢速雜湊」的場景。常見的 MD5 或 SHA-1 由於運算速度過快，在現代硬體攻擊下已不再安全。針對密碼儲存，應優先選擇專為抵禦暴力破解設計的慢速演算法，如 Argon2、bcrypt 或 scrypt。這些演算法透過增加計算成本（Work Factor），讓駭客在嘗試暴力破解時，硬體資源的消耗呈現指數級增長。
加密在傳輸中的必要性
如果說雜湊是保護資料庫裡的「靜態密碼」，那麼傳輸層加密（如 TLS/SSL）則是保護密碼在網路傳輸過程中的「動態安全」。即使你的雜湊機制再完美，若在傳輸過程中未啟用 HTTPS，密碼仍可能在中間人攻擊（MITM）中被攔截。因此，密碼安全必須是「端到端」的完整防護，而非僅僅依賴後端的儲存策略。
常見的資安誤區診斷表
下表整理了常見的資安迷思與其實際風險，幫助您在設計系統或日常使用時進行自我檢查。
| 常見迷思 | 實際風險 | 修正策略 |
|---|---|---|
| 使用 MD5 儲存密碼 | 運算過快，極易被彩虹表破解 | 改用 Argon2 或 bcrypt |
| 將密碼加密儲存以便還原 | 一旦密鑰外洩，所有密碼即暴露 | 僅使用單向雜湊儲存，不可還原 |
| 要求用戶定期更換密碼 | 導致用戶設定規律性密碼 | 改採多重驗證（MFA）與異常登入監控 |
| 所有服務共用同一組密碼 | 單點失效，引發骨牌效應 | 強制使用密碼管理員產生隨機密碼 |
實作策略：建構強韌的密碼驗證流程
要建立一套現代化的密碼驗證系統，開發者與使用者必須共同遵循一套標準化流程。以下是針對系統設計層面的實作檢查清單，確保你的架構符合當前安全趨勢。
- 強制加鹽（Salting）： 確保每個使用者帳號的雜湊值均加入唯一的隨機鹽值，徹底阻斷彩虹表攻擊。
- 導入慢速雜湊函數： 將 Work Factor 設定為系統硬體能負荷的最高上限，增加暴力破解的時間成本。
- 支援多重驗證（MFA）： 密碼僅作為第一道防線，必須強制導入 TOTP（基於時間的一次性密碼）或 Passkey。
- 實施速率限制（Rate Limiting）： 在登入介面針對特定 IP 或帳號進行嘗試次數限制，防止自動化腳本攻擊。
- 監控異常行為： 若偵測到未知裝置登入，應立即觸發郵件通知並暫時鎖定該帳號。
關於加鹽與加胡椒的細節差異
在雜湊的實作中，「鹽值（Salt）」與「胡椒（Pepper）」是兩個常被討論的機制。鹽值通常儲存在資料庫中，與密碼雜湊值一同儲存，其主要目的在於確保即使兩個使用者設定相同的密碼，其雜湊後的結果也不會相同。這種做法能有效防止預先計算好的雜湊表攻擊。
相比之下，胡椒則是存放在應用程式伺服器環境變數中的祕密值，不儲存在資料庫內。即便駭客竊取了整個資料庫，沒有胡椒的參與，也無法進行雜湊比對。這種縱深防禦的策略，為密碼安全提供了額外的保護層，是高安全性系統的標準配備。
常見的實作陷阱：為什麼你的防護會失效？
許多系統在實作時，往往犯了「以為有做就是安全」的錯誤。例如，雖然使用了 bcrypt，但卻因為 Work Factor 設定過低，導致在 GPU 叢集攻擊下仍顯得不堪一擊。此外，忽略了密碼重置功能的安全性也是常見的盲點。若重置連結的 Token 設計過於簡單，駭客同樣可以透過預測 Token 來重設用戶密碼。
另一個常見的問題是「密碼強度檢查」過於僵化。許多網站會檢查密碼是否包含特殊字元，卻沒檢查密碼是否曾出現在已知的洩漏清單中。現代安全實作應優先檢查密碼的「熵（Entropy）」與「洩漏紀錄」，而非僅僅檢查字元組合。透過整合 Have I Been Pwned 等 API，能更有效率地過濾掉那些已被駭客掌握的密碼組合。
延伸思考：邁向無密碼的未來架構
隨著資安威脅日新月異，我們必須意識到，密碼本身就是一個脆弱的認證載體。無論我們如何優化雜湊演算法，人類的記憶力與行為模式始終是系統中最大的安全弱點。因此，將認證機制從「使用者所知道的（密碼）」轉向「使用者所擁有的（裝置、生物辨識）」是未來的必然趨勢。
在設計系統時，建議將密碼視為「遺留架構」，並優先推廣 Passkey 或 WebAuthn 等技術。這些技術利用硬體安全晶片進行簽章驗證，從根本上消除了釣魚攻擊與資料庫密碼洩漏的風險。對於開發者而言，現在即是開始規劃轉型路徑的最佳時機，而非持續在修補舊有的密碼儲存機制上耗費資源。