將參數儲存在 Argon2 雜湊中作為潛在的安全問題？
我真的在努力確保在密碼儲存方面遵循最佳實踐，在四處尋找一個好的算法之後，我發現 Argon2 是“下一件大事”。我一直在使用 Liphsoft (Liphsoft.Crypto.Argon2) 提供的 NuGet 包在 VB.Net 中對其進行測試。
預設情況下，看起來散列算法的參數儲存在散列本身中。我理解（或者至少我認為我理解）如果您決定更改參數，這假設可以更容易地將其遷移到新的雜湊值。
我的問題是，通過在雜湊本身中提供雜湊算法的參數是否會降低安全性？我目前正在考慮僅刪除資訊並將參數值隱藏在程式碼中，這樣如果有人掌握了雜湊，他們就不會立即看到“哦，他們正在使用帶有這些特定參數的 Argon2。 " 我應該擔心嗎？
非常感謝任何回饋。謝謝！
發帖前我也看過這個問題：Argon2 output length and parameter storage?
首先，在密碼學領域，追隨“下一件大事”通常不是一個好主意。你應該強烈比起新的程式碼和算法，更喜歡經過實戰考驗的程式碼和算法。在這種特殊情況下，共識主要是 Argon2 極不可能成為使其在實踐中比 scrypt、bcrypt 或 PBKDF2 更糟的攻擊的受害者，因此選擇 Argon2 不一定是錯誤的；只需考慮一下，當涉及到密碼學時，您的直覺應該會驅使您做出更成熟、更保守的選擇。您還應該更喜歡現成的算法和實現，而不是您對其進行自定義修改的版本；您通過誤解或通過錯誤使事情變得更弱的可能性比您充分解決真正的弱點要大幾個數量級。可以這樣想：如果您的擔憂是基於真實的事情，並且它們像您認為的那樣容易解決，已經為你處理好了。
其次，需要參數才能重新計算散列。如果在最初對密碼進行雜湊處理時指定不同的硬度約束，則會得到不同的結果。因此，如果您在嘗試驗證雜湊時不知道這些參數，則必須嘗試這些參數的每種組合，直到您有幸偶然發現結果如果您將這些參數直接儲存在程式碼中，您從技術上講，不需要將它們與雜湊本身放在一起。然而，這些參數不應該一成不變：它們應該隨著記憶體變得更便宜和硬體變得更快而不斷增加。一些庫允許您在第一次實例化庫時通過“校準”計算來動態執行此操作，
作為失去這種靈活性的交換，您在安全性方面獲得了相對較小的好處。如果您以合理的成本（> 0.1 秒）使用 Argon2，攻擊者應該花費不切實際的時間來恢復除了最微不足道的密碼之外的所有密碼；針對 10,000 個使用者的數據庫執行最常見的 1,000 個密碼列表將花費十多天的 CPU 時間，即使在這裡，您最好通過阻止使用者使用這些列表中的密碼來緩解這種情況。
仍然有一個不可否認的，即使是很小的好處。我們能在沒有缺點的情況下獲得這種好處嗎？是的。與其隱藏成本參數（它對熵的影響不大），不如在將密碼發送到 Argon2 之前計算密碼的 HMAC。通過使用密鑰並首先計算 HMAC，您可以保持成本變數的靈活性，但您也可以防止攻擊者有任何測試密碼的能力，除非他們還獲得了 HMAC 密鑰，它的熵遠大於做你的成本參數。
編輯：要注意的另一件事是，您的建議並沒有像您想像的那樣真正捍衛。正如我在對@LuisCabrillo 的回答的評論中指出的那樣，這些東西的總和可能有 16 位熵。面對一個聰明的攻擊者，他們使用他們已經知道的密碼在您的網站上創建了一個帳戶，您現在幾乎沒有採取任何措施來阻止他們：他們知道密碼和匹配的雜湊值，因此只需要遍歷每種可能性一次，直到他們確定您的算法和成本因素。然後他們可以照常攻擊您的密碼數據庫。