使用加密隨機密碼作為密碼和鹽
這個問題是理論上的，但有助於我的理解。
我所有的密碼都是使用64 個隨機字母（大寫和小寫）和數字安全生成的。
使用argon2i密碼散列算法，如果我為消息和鹽提供這個長隨機密碼，它是否仍然保持相當安全。在所有情況下，鹽都將等於被散列的密碼。
我對 salts 的理解讓我想到，由於密碼已經足夠複雜和隨機，salt 總是與 message/pw 具有相同的精確值並不一定會使密碼合理地被發現。這如何適用於 argon2i？
salt 的全部意義在於設置密碼操作是唯一的，這樣攻擊者在針對多個帳戶（同一伺服器上的多個使用者、多個伺服器或兩者）時無法重用工作。使用密碼作為鹽完全違背了目的。
鹽不需要是不可猜測的或秘密的。它幾乎總是一個長的隨機字元串的原因是在統計上是唯一的（在字面意義上），而不是安全唯一：它是隨機的，因此兩個設置密碼意外使用相同鹽的機會可以忽略不計，並非如此對手無法猜到。唯一的伺服器名稱加上執行緒標識符加上時間戳也可以，但這並不常見，因為很難確保在所有環境中都以這種方式獲得唯一的字元串（例如在複製的虛擬機上）。
大多數庫在設置密碼操作期間自動生成隨機鹽，並將鹽與其他元數據與密碼散列函式的輸出一起儲存。在大多數程式環境中，您需要做一些額外的處理以在 set-password 和 check-password 操作期間強制使用不同的鹽，並更改儲存格式以便不儲存鹽（否則您將只是以純文字形式儲存您的密碼）。不要做這種額外的處理：它會增加複雜性，即使實現完美也會降低安全性。
在 62 個字元的字母表上包含 64 個字元的密碼具有大約 381 位的熵，這太過分了：它保護的任何數據，或者它在通信中的傳輸，最多只能由 256 位密鑰保護。43 個字元會給你 256 位。20 個字元會給你 119 位。使用這麼長的密碼（並且隨機生成，否則長度無關緊要），您實際上不需要密碼散列機制：密碼散列機制與普通散列相反的目的是使猜測更加困難，但猜測 119 位秘密首先是不可行的。所以從理論上來說，因為你的密碼已經是高熵的了，使用 Argon2i 或任何其他帶有缺陷鹽的密碼散列函式實際上不會降低系統的安全性。但是您仍然不應該這樣做，以防系統曾經使用“正常”（低熵）密碼，因為它會增加實現的複雜性。