用于密碼哈希的非隨機鹽我最近從這個問題中了解到，在下面的整個討論中，我（我確信其他人也這樣做）有點令人困惑：我一直稱之為彩虹表，實際上稱為哈希表。彩虹桌是更復雜的生物，實際上是Hellman Hash Chains的變種。雖然我認為答案仍然是相同的（因為它不歸結為密碼分析），但有些討論可能有點偏差。問題是：“ 什么是彩虹表，它們是如何使用的？ ”通常，我總是建議使用加密強隨機值作為salt，與哈希函數(shù)（例如密碼）一起使用，例如防止彩虹表攻擊。但實際上鹽是隨機的加密必要嗎？在這方面，任何唯一值（每個用戶唯一，例如userId）是否足夠？實際上，它會阻止使用單個Rainbow Table來破解系統(tǒng)中的所有（或大多數(shù)）密碼...... 但是缺少熵真的會削弱散列函數(shù)的加密強度嗎？注意，我不是在問為什么要使用salt，如何保護它（它不需要），使用單個常量哈希（不要），或者使用什么樣的哈希函數(shù)。無論鹽是否需要熵。感謝所有答案到目前為止，但我想集中討論我（有點）不太熟悉的領域。主要是對密碼分析的影響 - 如果有人從密碼數(shù)學PoV獲得一些輸入，我會非常感激。此外，如果還有其他未被考慮的向量，那也是很好的輸入（參見@Dave Sherohman指向多個系統(tǒng)）。除此之外，如果您有任何理論，想法或最佳實踐 - 請使用證據(jù)，攻擊情景或經(jīng)驗證據(jù)來支持這一點?；蛘呱踔潦强山邮艿臋嗪獾挠行Э紤]因素......我對該主題的最佳實踐（資本B資本P）很熟悉，我想證明這實際上提供了什么價值。編輯：這里有一些非常好的答案，但我認為正如@Dave所說，它歸結為Rainbow Tables的常見用戶名......以及可能不太常見的名稱。但是，如果我的用戶名是全局唯一的呢？不一定是我的系統(tǒng)唯一，但每個用戶 - 例如電子郵件地址。沒有動力為單個用戶構建RT（正如@Dave強調的那樣，鹽不會保密），這仍然會阻止群集。唯一的問題是我可能在不同的網(wǎng)站上有相同的電子郵件和密碼 - 但鹽無論如何都不會阻止它。因此，它回歸到密碼分析 - 是否需要熵？（我目前的想法是從密碼分析的角度來看沒有必要，但這是出于其他實際原因。）