密碼散列，鹽值和哈希值的存儲

Question

假設您可以自由決定如何將密碼散列存儲在DBMS中。像這樣的計劃有明顯的弱點嗎？

要創建存儲在所述DBMS的散列值，取：

• 的值，它是唯一的DBMS服務器實例作爲鹽的一部分，
• 而用戶名作爲的第二部分鹽，
• 並創建實際密碼鹽的級聯，
• 並採用SHA-256算法散列整個字符串，
• 並將結果存儲在數據庫管理系統。

這意味着任何想要碰撞的人都應該分別爲每個用戶名和每個DBMS服務器實例單獨完成工作。我打算保持實際散列機制的靈活性，以允許使用仍在使用中的新的NIST標準散列算法（SHA-3）。

'DBMS服務器實例獨有的值'不需要保密 - 儘管它不會隨便泄露。目的是確保如果某人在不同的DBMS服務器實例中使用相同的密碼，則記錄的散列值將會不同。同樣，用戶名也不會是祕密 - 只是密碼本身。

密碼優先，用戶名和'唯一值'第二，或三個數據源的任何其他排列是否有優勢？或者交叉字符串呢？

我是否需要添加（並記錄）隨機salt值（每個密碼）以及上面的信息？ （優點：用戶可以重新使用密碼，並且可能會在數據庫中記錄不同的散列表。缺點：必須記錄鹽分，我認爲這樣做的好處遠遠超過了缺點。）

相當多的SO問題相關 - 這個名單不太可能是全面的：

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

我認爲，這些問題的答案支持我的算法（但如果你只是使用一個隨機的鹽，然後將「每個服務器的獨特價值」和用戶名組成部分並不重要）。

Answer 1

鹽只需要是隨機的和獨特的。它可以自由知道，因爲它不會幫助攻擊者。許多系統會將純文本salt存儲在數據庫中散列密碼旁邊的列中。

鹽有助於確保如果兩個人（用戶A和用戶B）碰巧共享相同的密碼，它並不明顯。沒有每個密碼的隨機和唯一的salt值，散列值將是相同的，顯然如果用戶A的密碼被破解，則用戶B必須擁有相同的密碼。

它還有助於防止哈希字典可以與已知密碼匹配的攻擊。例如彩虹桌。

此外，使用內置「工作因子」的算法也意味着，隨着計算能力的增加，算法必須通過創建哈希的工作也可以增加。例如，bcrypt。這意味着暴力攻擊的經濟性變得站不住腳。據推測，創建已知哈希表的時間變得更加困難，因爲它們需要更長的時間才能創建。 「工作因素」的變化意味着需要建立更多的表格。

Answer 2

爲什麼不向密碼添加一個隨機鹽並散列該組合。接下來將散列和salt連接成單個字節[]並將其存儲在數據庫中？

隨機鹽的優點是用戶可以自由更改它的用戶名。鹽不必是保密的，因爲它用於防止字典攻擊。

Answer 3

我認爲你是過度複雜的問題。

開始的問題：

1. 你想保護弱口令？
2. 你想減輕彩虹攻擊嗎？

您提出的機制可以防止簡單的彩虹攻擊，即使用戶A和用戶B擁有相同的密碼，哈希密碼也會不同。它看起來像是一個相當複雜的方法，可以醃製一個過於複雜的密碼。

• 將數據庫遷移到其他服務器時會發生什麼？
  • 您可以更改每個DB值的唯一值嗎？如果是，則可以生成全局彩虹表，如果不是，則不能恢復您的DB。

相反，我只想補充額外的列和存儲適當的隨機鹽。這可以防止任何形式的彩虹攻擊。跨多個部署。

但是，它不會保護你免受暴力攻擊。因此，如果您試圖保護擁有蹩腳密碼的用戶，則需要查看其他地方。例如，如果用戶有4個字母的密碼，即使使用salt和最新的散列算法，它也可能在幾秒鐘內破解。

Answer 4

我想你應該問自己：「你希望通過使這個過程複雜化，而不是僅僅產生一個隨機鹽值並存儲它，你會得到什麼？」您製作算法越複雜，您越有可能無意中引入弱點。無論我怎麼說，這可能聽起來都很尖銳，但它的含義很有幫助 - 你的應用程序有什麼特別之處，它需要一個奇特的新密碼哈希算法？