KDF Salt：如何/何時可以公開？
崗位結構：
- 研究了先前的源材料
- 問題和詳細資訊
- 假設的威脅模型
- 例子
- 假設
- 澄清
研究了先前的源材料
0.1。RFC 2898
0.2。HAC（應用密碼學手冊）
0.3。加密 101
0.4。SE 回答（例如：如果攻擊者知道 salt 和 hash，salt 如何有效？）和（Use of salt to hash a password）
0.5 2018 DBIR
問題：
使用已知鹽和低熵密碼的 KDF 如何比使用鹽的所謂“完全損壞且根本不安全”的原始散列更安全？
1.1 細節：
根據可用的主題材料，KDF 鹽不需要保密。
建議是否暗示威脅模型中的一個初始假設，即使用者提供的密鑰/密碼總是具有足夠高的熵，或者不會是弱熵的實例？還是該建議僅適用於每次使用不同的鹽/密鑰定期加密相同或不同數據的特定情況？
Crypto101 的作者寫了關於通用 Crypto Hash Primitives 的文章：
“雖然這
$$ rainbow tables based on a known single salt $$本來可以通過為每個使用者使用不同的鹽來防止，使用加密散列和每個使用者的鹽的系統今天仍然被認為從根本上被破壞了；它們只是更難破解，但一點也不安全。”
如果威脅模型總是假設（因為它應該）使用者提供的密鑰可能很弱，那麼使用具有已知鹽的 KDF 如何比上述使用具有未知（高熵）的 Hash Primitive 的破壞模式更安全） 鹽？（請參閱此處對明顯計數器的回答的澄清）
問題的（方面）假設的威脅模型：
2.1 使用者創建低熵密碼（TW37VE），需要保存，用於登錄。
2.2 攻擊者將使用相同的 kdf（具有正確猜測的迭代）從這個常見的低熵密碼計算密鑰。
2.3 Salt 需要將熵添加到使用者提供的密碼（編輯：一個錯字最初說明“秘密密鑰”而不是這裡的密碼）——假定來自低熵空間——將假定這裡是已知的威脅行為者（基於文件中的建議）。
2.4 KDF 的慢速計算/高記憶體成本是可以承受的，即使僅用於訪問單個使用者數據：例如，可能是內部威脅參與者願意為特定使用者訪問數據的情況。
2.5 內部/內部威脅行為者：根據 2018 DBIR，28% 的報告數據洩露涉及內部/內部行為者。因此，威脅模型將內部參與者視為潛在威脅，即使在沒有外部參與者的情況下也是如此。因此，也需要確保鹽的安全。（有關明顯計數器的答案，請參閱說明）
範例：
使用過的 KDF：
假設密碼 TW37VE，PBKDF2_SHA256 使用隨機鹽 0CE@N 和 100000 次迭代生成一個密鑰，因此派生密鑰為：
kdf(TW37VE, 0CE@N’s, 100000) : pbkdf2-sha256 $ 100000 $ OCE@N’s$!@#%^&
威脅 KDF：kdf（harvested-weak-password = TW37VE，not-secret-salt = 0CE@N’s，guessed-iterations = 100000）：
pbkdf2-sha256 $ 100000 $ OCE@N’s$!@#%^&
如果合法使用者可以使用已知的低熵密碼和檢索到的鹽來驗證自己，那麼在攻擊者使用（a）獲取的密碼（或者它是預先計算的字典/彩虹雜湊）和（b ) 不保密的鹽？
即使威脅參與者掃描密碼並將密碼與 64 位鹽密鑰空間進行匹配是微不足道的，由此產生的潛在延遲也不會受到傷害。
問題中的假設：
4.1。派生密鑰的非隨機部分與安全模型強度無關。
4.2. 攻擊者也可以將 pbkdf2-sha256 與已知的鹽、收穫的密鑰和正確猜測的迭代一起使用。
澄清
5.1 了解使用某些基於原語的方法的缺點；並且，隨機鹽 KDF 在區分相似內容方面的優勢也是如此。
5.2 問題的重點是為什麼在假設的威脅模型下基於原語的模式被認為是被破壞的，而在相似條件下簡單地屈服於相似威脅模型的 KDF 模式被認為是對前者的改進。
5.3 DBIR 報告的“28% 內部參與者”數字包括具有不同行為的不同類型的參與者，儘管可能很小，但在這種情況下，假設是來自應用程序伺服器團隊的開發人員流氓（或者可能總是很糟糕？）。
5.4 本土卷：有一種方法可以保持 salt 加密，除非整個數據庫伺服器受到威脅，否則威脅者無需訪問 salt-decryption 密鑰。
概括：
重申一下，當暴露 kdf 鹽可能有潛在的危害性和安全性等同於不安全的原始方法時，如何不將 kdf 鹽保密？
使用已知鹽和低熵密碼的 KDF 如何比使用鹽的所謂“完全損壞且根本不安全”的原始散列更安全？
密碼雜湊或基於密碼的密鑰派生函式 (PBKDF) 更安全，因為它還使用密鑰拉伸技術（工作因素或迭代計數）使攻擊者更難“猜測”密碼。這些功能可能難以記憶，使對手更難攻擊密碼。由於工作因素僅增加了一個恆定的時間因素，因此它提供的保護仍然有限。
請注意，這特別適用於基於密碼的 KDF。還有一些 KBKDF，例如 HKDF，可能使用鹽，但不提供鍵拉伸。
如果威脅模型總是假設（因為它應該）使用者提供的密鑰可能很弱，那麼使用具有已知鹽的 KDF 如何比上述使用具有未知（高熵）的 Hash Primitive 的破壞模式更安全） 鹽？（請參閱此處對明顯計數器的回答的澄清）
使用者不提供（對稱）密鑰，使用者提供密碼。使用者在輸入 16 字節二進制值方面是出了名的糟糕。
“秘鹽”也稱為胡椒。如果可以保留一個秘密辣椒，那麼是的，這將比使用鹽更安全，即使後者在 PBKDF 中使用。如果多個使用者的胡椒值相同，那麼您仍然應該使用額外的鹽；否則很容易辨識出具有相同密碼的使用者。
通常假設沒有可用的安全密鑰儲存，因此使用辣椒根本不可行。 顯然，辣椒不能以明文形式儲存在同一個數據庫中。
由於 KDF 提供了密碼和鹽的顯式輸入（但不幸的是，通常不是單獨的鹽和胡椒），因此使用基於密鑰的 KDF 或迭代計數為 1 的 PBKDF 比使用加密散列更好，如果只是為了清楚在散列輸入之前分離輸入。
例如 $ \text{Hash}(P_0P_1|S_0) $ 和 $ \text{Hash}(P_0|S_0S_1) $ 可以散列到相同的值，而這不是預期的 $ \text{KDF}(P_0P_1, S_0) $ 和 $ \text{KDF}(P_0, S_0S_1) $ .
salt 的目的不是使從密碼計算密鑰變得更加困難。目的是使其唯一，即使多個使用者共享相同的密碼。
如果 1000 個使用者共享密碼“password1”並且沒有鹽，那麼有權訪問密碼雜湊數據庫的攻擊者只需正確猜測其中一個使用者，其餘所有雜湊都是相同的。
如果 1000 個使用者共享密碼“password1”並且他們每個人都有一個唯一的鹽，那麼有權訪問密碼數據庫的攻擊者必須依次正確猜測每個使用者，所有雜湊都是唯一的。因此，攻擊者獲取所有使用者的雜湊值要困難 1000 倍。為任何單個使用者獲取雜湊的難度沒有改變。
鹽用於防止可以訪問整個雜湊密碼數據庫的攻擊者。他們已經獲得了數據庫訪問權限，因此他們很可能也可以訪問儲存在伺服器上的任何秘密值。特別是因為伺服器需要訪問這些秘密才能計算使用者登錄的密碼雜湊。假設您可以保密違反了威脅模型的假設，因此不值得考慮。如果您可以在伺服器上可靠地保密，您不妨將整個密碼數據庫儲存在那裡，而不必擔心鹽。