多年來，存儲密碼的標準機制已經發展。在開始時，密碼以純文本格式存儲。假設密碼是安全的，因為數據存儲密碼保存在所需的憑據中以訪問它。但是，惡意用戶能夠找到使用SQL注入等攻擊獲取用戶名和密碼的大量“數據轉儲”的方法。隨著越來越多的用戶憑證成為公共安全專家意識到我們需要做更多的工作來保護用戶密碼。 然后鼓勵開發人員在通過單向散列（如SHA-256）運行密碼后存儲密碼。當用戶嘗試進行身份驗證時，散列密碼將與他們鍵入的密碼的哈希值進行比較。這意味著系統只需要存儲密碼的單向散列。如果發生了破壞，則只暴露密碼的單向哈希。由于哈希是一種方式，并且在計算上難以猜測給定哈希的密碼，因此在系統中找出每個密碼是不值得的。為了打敗這個新系統，惡意用戶決定創建名為Rainbow Tables的查找表。他們不是每次都在猜測每個密碼，而是計算密碼一次并將其存儲在查找表中。 為了降低Rainbow Tables的有效性，鼓勵開發人員使用salted密碼。不是僅使用密碼作為哈希函數的輸入，而是為每個用戶的密碼生成隨機字節（稱為鹽）。 salt和用戶的密碼將通過哈希函數運行，該哈希函數產生唯一的哈希值。鹽將以明文形式存儲在用戶密碼旁邊。然后，當用戶嘗試進行身份驗證時，散列密碼將與存儲的salt的哈希值和他們鍵入的密碼進行比較。獨特的鹽意味著Rainbow Tables不再有效，因為每個鹽和密碼組合的哈希值都不同。 在現代，我們意識到加密哈希（如SHA-256）不再安全。原因是，使用現代硬件，我們可以每秒執行數十億次哈希計算。這意味著我們可以輕松地單獨破解每個密碼。 現在鼓勵開發人員利用自適應單向函數來存儲密碼。使用自適應單向函數驗證密碼是故意的資源（即CPU，內存等）密集型。自適應單向函數允許配置“工作因子”，隨著硬件變得越來越好。建議將“工作因素”調整為大約1秒鐘以驗證系統上的密碼。這種折衷是為了讓攻擊者難以破解密碼，但不是那么昂貴，這給你自己的系統帶來了過多的負擔。 Spring Security試圖為“工作因素”提供一個良好的起點，但鼓勵用戶為自己的系統定制“工作因素”，因為不同系統的性能會有很大差異。應該使用的自適應單向函數的示例包括bcrypt，PBKDF2，scrypt和Argon2。 由于自適應單向函數是有意為資源密集型的，因此為每個請求驗證用戶名和密碼會顯著降低應用程序的性能。 Spring Security（或任何其他庫）無法加速密碼驗證，因為通過使驗證資源密集，可以獲得安全性。鼓勵用戶交換短期憑證（即會話，OAuth令牌等）的長期憑證（即用戶名和密碼）。短期憑證可以快速驗證，而不會有任何安全損失。