儲存鹽加密是個好主意嗎？
我讀過將密碼雜湊儲存在數據庫中，您可以將鹽以明文形式儲存在實際雜湊旁邊，而不會損害安全性。我在想可以從使用者的密碼中派生一個密鑰，並使用該密鑰來加密隨機鹽，這樣每次使用者登錄時，鹽都會被解密，並且鹽可以在那時與密碼連接並散列，並檢查它是否有效。這樣，如果數據庫遭到破壞，salt 值本身將取決於使用者的密碼，攻擊者將沒有希望知道 salt。這個計劃有什麼額外的好處嗎？
這個計劃有什麼額外的好處嗎？
並不真地; 密碼雜湊以這種形式儲存雜湊密碼：
$$ H( \text{password}, \text{salt} ) $$
在哪裡 $ H $ 是一些難以計算的雜湊函式。您的建議是將其替換為：
$$ H( \text{password}, D( \text{password}, \text{encrypted_salt}) ) $$
（在哪裡 $ D $ 是解密函式）。但是，這可以用原始格式重寫，如：
$$ H’( \text{password}, \text{salt’} ) $$
在哪裡 $ H’(A, B) = H( A, D( A, B )) $ ， 和 $ salt’ $ 是數據庫中的加密鹽。特別是，針對第一種形式的散列格式的任何攻擊也適用於第二種形式生成的散列格式。
如果我們“加密”，將會有什麼增量改進
$$ 1 $$salt，不是使用密碼，而是使用儲存在數據庫之外的密鑰（例如，在硬體安全模組或 HSM 中）；為了額外的安全性，我們永遠不會將密鑰導入記憶體，而是讓 HSM 為我們解密加密的鹽（並將其作為解密過程的一部分加入密碼，例如作為調整）。 這樣做意味著對手恢復數據庫是不夠的，但他們還需要鹽的解密版本，或者用於解密鹽的密鑰。而且，如果我們將密鑰放在 HSM 中，他們將無法獲得該密鑰，並且如果我們讓 HSM 在解密過程中加入密碼，那麼他們不僅需要獲得對伺服器的控制權（以便他們可以向 HSM 發出解密命令），但他們只能在 HSM 可以解密的速度下測試對密碼的猜測，無論他有什麼其他可用的計算資源。
$$ 1 $$: 嚇唬人的引號是因為我們實際上並不需要可逆加密；我們能做的是讓“解密”過程成為 $ D(\text{key}, \text{encrypted_salt}, \text{password}) = Hash( \text{key}, \text{encrypted_salt}, \text{password} ) $ . 然後，我們實際上不會選擇鹽；相反，我們會選擇一個隨機加密的鹽，根據它計算鹽，然後將該值傳遞給我們的密碼散列函式。