為使用者帳戶創建鹽時是否需要使用 CSPRNG？
我不確定是否需要使用 CSPRNG 為每個使用者帳戶創建鹽。
我找到了“ Qt/C++（跨平台）中的加密安全偽隨機數生成器”（在 StackOverflow 上），其中包含一些有用的資訊，但我無法完全理解其背後的原因。
如果攻擊者可以訪問我的使用者數據庫表的副本，其中包含每個 salt 和相關的加鹽密碼，我無法理解 CSPRNG 如何比 SHA12 散列 UUID 更安全。有人可以詳細說明嗎？
回答你的問題
如果攻擊者可以訪問我的使用者數據庫表的副本，其中包含每個 salt 和相關的加鹽密碼，我無法理解 CSPRNG 如何比 SHA12 散列 UUID 更安全。有人可以詳細說明嗎？
我不確定您是否只閱讀過StackOverflow 上的“ Qt/C++（跨平台）中的加密安全偽隨機數生成器”問題，或者您是否也注意到了已接受的答案。答案實際上在這裡回答了您的問題，就像它在 StackOverflow 上回答了問題一樣。
如果您認為您需要一個加密安全的 PRNG 來生成鹽，那麼我必須告訴您，您不了解鹽是什麼以及它如何工作以及為什麼工作以及它對哪些類型的攻擊有用。
salt 必須以明文形式儲存在加鹽密碼的雜湊值旁邊這一簡單事實應該表明，您實際上並不需要用於 salt 的加密安全 PRNG - 或任何 PRNG。坦率地說，您可以擁有一個簡單的 64 位數字，每次需要新鹽時，您都會將其加一，它與加密安全 PRNG 生成的鹽一樣安全。
即使該答案是在 2012 年發布的，但情況並沒有改變，它仍然有效。
這就是 CodesInChaos 已經正確評論的原因……
鹽只需要唯一性，所以 UUID 就可以了。CSPRNG 只是生成鹽的最簡單方法，而不是唯一的方法。
並引用：
如果您更喜歡一個非常好的 UUID，但我不知道您為什麼要在數據庫端而不是應用程序上實現密碼散列。一般來說，我建議使用同時處理散列和加鹽的更高級別的 API。例如 php 的
password_hash/password_verify函式。在不太可能的情況下，您仍然不確定鹽以及它們存在的確切原因是什麼，我想向您指出一個問題“您能幫我理解什麼是加密“鹽”嗎？“及其公認的答案，它使用不同的措辭來解釋事物。引用與您的詳細說明請求最相關的已接受答案的一部分：
只需添加鹽以使通用密碼不常見。鹽值是隨機生成的，可以相當小，唯一的目的是降低在任何預先計算的表中找到散列值的機率。組合鹽和密碼的一種常見方法是簡單地將它們連接起來，即儲存的雜湊值為 Hash(salt||password)。通用密碼password1 現在神奇地變成了例如6$dK,3password1，並且不太可能在表中找到。
鹽可以完全以明文形式儲存在數據庫中，位於散列值旁邊。一旦攻擊者擁有數據庫並想要找到密碼，他需要為每個鹽單獨生成預先計算的表，這是一個昂貴的操作。
除了問答之外，您可能還想在 Crypto.SE 中搜尋與“鹽”相關的問答，這可能會幫助您完全掌握與鹽相關的內容。眾多範例之一：“為什麼不加密鹽？”
深入了解您的評論
我問是因為我不同意這是最簡單的。例如，MySQL 沒有本機 CSPRNG。
然後你可以使用一個簡單的遞增整數，或者任何其他會產生唯一鹽的東西。（請注意，“獨特”一詞已大寫作為提示，不代表皺眉的“線上喊叫”。）
有幾個原因。首先，數據庫伺服器比 Web 伺服器更安全。大多數情況下，它們只能通過應用程序訪問。
首先，我不得不不同意你的觀點，
database servers are way more secure than web servers因為事實並非如此。但是讓我們假設這是正確的（因為它與您的問題無關）。你必須記住，你的鹽只需要是獨一無二的，而不是秘密的。它不是“保護數據的秘密”。鹽僅用於使密碼之類的東西獨一無二——在攻擊者可能想要使用雜湊表之類的東西的情況下減慢攻擊者的速度。
其次，如果您的應用程序被盜，其上的 salt 邏輯會給攻擊者帶來優勢。
該論點在您的場景中並不真正相關，因為攻擊者仍然必須“猜測”密碼 - 這是真正的秘密（與鹽相比，更好的是：應用程序中的鹽漬功能）。您看到的優勢相當小……如果您仍然使用單獨的數據庫伺服器，您的攻擊者將在您的應用程序中查看可以產生鹽的函式……但他/她仍然沒有數據庫副本來用他/她複製您的應用程序使用的鹽的能力做任何有用的事情。為此，他們還需要竊取數據庫。
第三，我在數據庫中使用鹽，在應用程序中使用胡椒，這樣攻擊者需要同時竊取應用程序和數據庫。
偉大的。現在你需要做的就是明白鹽不是秘密。如果攻擊者知道鹽值是因為——例如——他/她竊取了您的數據庫副本並且可以快速輕鬆地查找它，那麼該攻擊者仍然需要暴力破解散列密碼。只有當使用已知在密碼學上不安全的雜湊時，您才會給攻擊者某種優勢。但是，如果您使用了一些理智且加密安全的東西（例如，SHA256、HMAC256 或 bcrypt），這樣的攻擊者仍將面臨漫長而痛苦的暴力破解嘗試。
知道如何重新創建鹽不會神奇地使暴力破解密碼雜湊變得容易。也就是說，除非您使用加密不安全的密碼散列方法（如普通 MD2 或 MD5）。因此，我傾向於建議——而不是試圖保護像鹽這樣的非秘密——你寧願專注於你如何散列真正的秘密……密碼。看，我在上面提到 SHA256 作為加密安全的散列函式，但它不是散列密碼等秘密的最佳方法。事實上，像 SHA256、HMAC256 或 SHA512（您在創建鹽時提到的）之類的東西並不打算用作密碼散列函式，並且應該 - 作為邏輯結果 - 不用於該目的（不是說你應該在創建獨特的鹽時避免使用它們）。這就是為什麼我也提到了bcrypt– 這是眾多專用密碼散列功能之一，在散列密碼方面絕對更值得推薦。除了 bcrypt 之外，其他好的密碼散列函式還有 scrypt、PBKDF2 或 Argon2。當您弄亂密碼散列部分時，這個星球上沒有鹽和/或胡椒可以拯救您，但如果您正確實施其餘密碼散列，即使是最糟糕的鹽也不會造成太大損害。
TL;博士
鹽不是秘密。他們不必保密；他們只需要是獨一無二的。
鹽（和辣椒）等非機密物質可以“露天”儲存；在您的情況下：作為數據庫中的純文字、整數值或二進制 blob。您的應用程序和數據庫都可以包含創建唯一鹽的功能。
與其嘗試“保護”鹽，更重要的是關注如何散列密碼。使用專用的密碼散列函式來執行此操作。