鹽長與總哈希長度比

Question

我正在使用KeyDerivation.Pbkdf2生成密碼哈希，我想知道一般建議是關於鹽長度與Pbkdf2輸出的總體哈希長度相比。

在下面的實現中，我使用HMACSHA512，並且假設salt是512位，並且hashBitLength也是512位。

KeyDerivation.Pbkdf2(password, salt, KeyDerivationPrf.HMACSHA512, iterationCount, hashBitLength/8); 

我見過它使用HMACSHA256一個例子，但它的鹽設置爲128位和整體哈希位長度爲256 爲什麼會採取這種方式？

我讀過512位可能是矯枉過正，但在存儲方面，它並不關心我（我不知道性能如何受到影響，但我沒有測試過）。

鹽的長度應與整個生成的散列值相同。 它應該是一半？ 或者它應該超過某個閾值並低於整體長度？

我的直覺告訴我做這件事的方式是正確的（除了可能是512位），因爲我懷疑我得到的是最大熵，但我不是密碼學家。

有人可以請澄清這一點嗎？

Answer 1

它確實不需要那麼大，但讓我們明白爲什麼。鹽的目的是：

1. 如果兩個人有相同的密碼，那麼'散列'結果不應該是相同的。
2. 預防rainbow table attacks。

第一點可以通過簡單地用一個計數器來完成 - 至少，防止重複自己的數據庫，但可能無法阻止你的數據庫中的密碼的哈希被相同的哈希在別人的數據庫中使用相同的密碼。這使我們想到了第二點。

如果只是簡單地使用一個從零開始的計數器，那麼可以基於它構造一個彩虹表。鹽越大，彩虹桌就越有可能有效。這些表與鹽的大小成指數增長，所以你的鹽真的不需要那麼大才能排除這種攻擊。

很難指出一個最小尺寸，但我可以向你保證，128位是綽綽有餘。作爲一名安全代碼審計員，我個人當然不會提出一個小至64位的鹽的問題。

有關此主題的安全建議的一個重大問題是沒有人分析過它 - 相反，您只是從聲稱自己是專家的人那裏獲得盲目推薦。我寫了一篇關於password processing的論文。具體見第3節關於我對鹽的咆哮。

備註：完全排除彩虹表，不要使用計數器。相反，選擇你的鹽'足夠大'（如上），並以不可預知的方式。