我很難理解在密碼或其他重要信息的數據庫受到危害時，如何將附加到哈希值的鹽幫助提高安全性。有人可以解釋鹽如何幫助存儲散列密碼？
如果鹽是，例如，「你好」，並追加到密碼「密碼」，則鹽和密碼被存儲在一起，「hellopassword」和散列以產生：
94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1)
與然後附加鹽：
hello$94e66f94517d606d5ad6d9191b980408952f2ed2
這是如何更安全？攻擊者知道鹽，所以現在可以計算密碼，沒有多少額外的困難......對吧？或者我從根本上誤解了什麼？
不，沒有「小額外困難」 - 可能會有更大的難度。
想象一下，有二十億個通用密碼。對所有這些進行散列並存儲結果很容易。那麼如果你有一個無碼密碼哈希，你可以檢查哪些通用密碼匹配給定的哈希。
現在比較，用鹽醃哈希......現在你有兩個十億常用的密碼，而且數十億可能形成的鹽。計算全部可能的鹽/密碼組合將需要很多很長時間 - 希望變得不可行。
此外，這意味着即使兩個人擁有相同的密碼，他們很可能會擁有不同的哈希 - 因此，一位用戶在泄露密碼時不小心不會冒險另一個用戶的安全。
見Wikipedia entry（如果你還沒有的話）以獲得更多關於這一點。
鹽有助於2種方式：
1）當兩個（或更多）的人使用相同的密碼，不加鹽，你可以看到誰使用相同的密碼（哈希值都相同）。所以從理論上講，如果那個人知道那些人的密碼中的一個，他就知道每個人的密碼都是相同的哈希值。這是一個小原因。
2）的主要原因是爲了防止通常被稱爲字典攻擊或彩虹攻擊。在這些攻擊中，有人使用預先計算的散列數據庫作爲常用密碼。這些數據庫通常都是演唱會的大小。但是，在這一點上，只需要對預先計算的散列列表進行哈希查找（哈希密碼）並查看相關的密碼是什麼。
通過使用salt值（通常您希望它是一個隨機數），哈希將不會匹配字典（它們預先計算所有可能的鹽值的所有密碼的機會指數更難）。所以即使你的用戶使用一個容易被攻擊的密碼，說「密碼」，這是幾乎保證任何在任何密碼字典/彩虹表，通過預先等待你的隨機鹽值，你使哈希幾乎保證是無用的給攻擊者。與此同時，由於salt只是以明文形式存儲，因此您可以很容易地將它添加到明文中，以便比較用戶輸入的密碼。
快速的問題。如果您每次使用不同的鹽散列密碼，並存儲結果值而不是密碼。你怎麼知道用什麼鹽來散列用戶在登錄時給的密碼，如果你不把散列存儲在任何地方？你不會將隨機鹽存儲在數據庫中嗎？ – 2010-09-04 17:29:26
如果您使用隨機鹽，則使用密碼進行存儲。否則，您不能重新創建哈希來檢查密碼。 – cHao 2010-09-04 17:31:09
這就是我想讀的;）檢查這個有趣的答案（伊恩在第一個答案中的評論）：http://stackoverflow.com/questions/615704/preferred-method-of-storing-passwords-in-database – 2010-09-04 17:40:50
鹽不會附加到散列，其附加到密碼THEN散列。這是更安全的，因爲黑客必須知道鹽和實際的密碼，你應該保護很重。：D
如果你想測試「密碼」是否是正確的密碼，你怎麼做這個不知道鹽，「你好」？據我所知，你必須儲存鹽...對嗎？ – 2010-09-04 17:12:06
您必須存儲它，但它可以作爲變量「存儲」在腳本中。儘管如此，硬編碼鹽只比鹽醃稍微好一些。 – cHao 2010-09-04 17:28:45
您通常不會在sha1之後追加salt，就像您在示例中一樣。相反，您可以將鹽添加到密碼「salt $ password」中，然後從'94e66f94517d606d5ad6d9191b980408952f2ed2'生成一個sha1。這樣鹽和密碼就不會暴露在任何數據結構中。 – tidwall 2010-09-04 17:11:01
你會如何保持鹽的祕密？你會把它作爲程序中硬編碼的祕密值嗎？ – 2010-09-04 17:14:55
沒有必要保守鹽的祕密 - 事實上，所有使用salt的Linux密碼哈希方案（這是所有常見的哈希方案）都會像您所做的那樣將salt加入哈希中。無論攻擊者是否知道鹽的含義，鹽的主要工作（使彩虹桌不可行）都可以實現，並且使用密碼存儲它可以很容易地隨意更換鹽，而無需讓所有用戶重置密碼。每個密碼甚至可以有不同的鹽分。 – cHao 2010-09-04 17:22:41