多重雜湊的安全隱患是什麼？

這個網站上有很多 關於散列密碼的 問題。但是，它們都沒有完全涵蓋這個主題。其中一個連結涵蓋了使用多種不同的雜湊算法；一個涵蓋一般散列，另一個涵蓋應如何傳輸密碼。但是，我想知道多次使用一個雜湊函式的安全隱患。

不久前我看到一篇文章說這不是一個好主意。但是，我想要一些明確的答案。那麼，使用這樣的雜湊系統有哪些安全隱患，無論好壞：

hash(hash(hash(password) + salt) + pepper)

換句話說，對密碼進行散列，然後用鹽對密碼的散列進行散列，然後用胡椒對這個散列進行散列。

多重散列本身並不是一個壞主意。不好的是試圖設計自己的非標準密碼散列方案，卻不了解這種方案需要哪些功能才能保證安全。

事實上，多次散列密碼可能是一個非常好的主意，只要你這樣做足夠多次。這是減慢散列過程的一種方法，因此使其更能抵抗暴力破解嘗試，這種技術稱為密鑰拉伸。這是任何好的現代密碼散列方案都應該做的事情，許多這樣的方案，如PBKDF2，實際上是通過多次散列密碼來實現的。

至於您的 範例hash(hash(hash(password) + salt) + pepper)，一般來說，這不會比 弱hash(password + salt + pepper)，但也不會明顯更強。要實現任何類型的有用密鑰拉伸，您需要至少迭代雜湊 1,000 次，最好接近 1,000,000 次（或者使用者願意等待的多次迭代）。

---

附言。對於任何想設計自己的密碼散列方案或評估現有方案的安全性的人，這裡有一個這樣的方案至少應該具有的屬性的快速清單：

1. 應該不可能直接從雜湊中重建有關密碼的任何資訊。（這是一個非常基本的要求。即使是任何加密散列函式（如SHA-2函式）的單個應用程序也足以確保這一點。）
2. 雜湊應該接受任意長的密碼片語，並且應該依賴於密碼片語的每一位。（同樣，這個要求應該是顯而易見的，但是一些非常古老和/或設計非常糟糕的雜湊方案，如DES-crypt可能會失敗。）如果為了可用性，密碼片語的某些功能（如周圍的空格或字母大小寫） ) 被故意忽略，使用者應該在選擇他們的密碼之前清楚地知道這一點。
3. 散列應該加鹽，這樣兩個具有相同密碼的使用者將不會得到相同的散列。理想情況下，鹽應該是全球唯一且不可預測的；它當然不應該只是使用者名。足夠長的隨機字元串（例如 10 個或更多 base64 字元）是可以的，但理想情況下，鹽還應包含其他希望唯一的元素（例如，使用者名、伺服器 ID 和時間戳的 SHA 雜湊）以確保唯一性，即使隨機數生成器失敗。
4. 除了鹽之外，散列方案可能依賴於密鑰（有時稱為“胡椒”）。但是，它的安全性絕不能僅僅依賴於這個密鑰的保密性。
5. 散列方案應該能夠抵抗暴力攻擊，這意味著散列的計算速度應該很慢。這可以通過迭代散列來實現，如上所述，或者通過為此目的設計的其他結構（如在scrypt）。慢度應該由一個可調整的參數來控制（理想情況下，應該根據可用的硬體自行調整）。特別是，不應該有任何“快捷方式”來檢查密碼的有效性，這比通過程式碼使用的標準方法要快得多。如果可能的話，散列方案也應該被設計成不適合大規模並行實現（例如在 GPU 上；scrypt 是這樣設計的，PBKDF2 不是）。此外，如果可能，在客戶端-伺服器應用程序中，大部分散列工作應解除安裝到客戶端（但散列方案的伺服器端部分本身仍應是安全的，即使客戶端行為不端）。
6. 應鼓勵使用者選擇長的、隨機生成但易於記憶的密碼（例如由diceware生成的密碼）。為此，使用者界面可以自動生成並向使用者建議這樣的密碼片語。（如果是這樣，應注意確保使用的隨機數生成器是高質量的，並且密碼不能被攻擊者擷取。）不應強迫使用者遵守低效和人為的要求，例如“密碼必須至少包含一個數字”，儘管使用不同字元集（包括非 ASCII Unicode 字元）的密碼當然不應該被禁止（或者，更糟糕的是，去掉這些字元）。

引用自：https://crypto.stackexchange.com/questions/21052