GUID 作為鹽
報價：
這些答案中的大多數都有點誤導，並證明了鹽和加密密鑰之間的混淆。包含鹽的目的是修改用於散列每個使用者密碼的函式，以便必須單獨攻擊每個儲存的密碼散列。唯一的安全要求是它們對每個使用者都是唯一的，它們不可預測或難以猜測沒有任何好處。
$$ … $$即使有 10 億註冊使用者，隨機 64 位鹽也不太可能重複，所以這應該沒問題。
由於鹽需要是唯一的並且GUID 是唯一的並且足夠長（128 位）：
將 GUID 作為鹽而不是CSPRNG是否安全？
（我能想到的唯一缺陷是 GUID 的生成是否會存在某種缺陷。）
大多數生成類型 4 UUID的系統，也就是“隨機 GUID”，通常已經使用 CSPRNG來生成它們。這對於防止生成的輸出中的衝突是必要的；從具有小狀態或從系統時間弱播種的隨機數生成器生成數千個 UUID 將很快開始生成非唯一的類型 4 UUID，並有望通過單元測試。
使用 CSPRNG 的範例包括 Java、Microsoft .net 和大多數數據庫中的 UUID 生成函式。
但是，情況並非總是如此，除非您可以驗證實現使用 CSPRNG 來生成類型 4 UUID ，否則不應依賴這種情況。
我實際上遇到了兩個獨立的本土 UUID 生成器，它們在 JavaScript 中使用 Math.random()。兩者都在測試中 <= 100k UUID 後產生了衝突（並且還在生產應用程序中產生了衝突，調試起來很有趣）。
簡而言之，鹽需要是唯一的，所以如果可以的話，直接使用 CSPRNG來生成 16 字節的鹽。如果您必須使用 UUID 函式，請確保它不會通過閱讀低級文件和直接測試（生成數百萬個 UUID 並檢查重複項）來產生衝突。
基於計數器/時間的 UUID 也可以合理地用於鹽，但再次通過直接測試驗證實現的唯一性。我遇到了一個基於時間的 UUID 生成器，如果由於計數器包裝不夠大而在緊密循環中呼叫，它會生成重複項。