是bcrypt用hmac'd密碼改進的嗎？

Question

給出：

$鹽 - 足夠的長度的僞隨機生成的字符串

$胡椒 - 足夠強的私鑰，只知道在密碼短語被存儲在DB的管理員

你會看到

$哈希= bcrypt（HMAC（$ userpassphrase，$辣椒），$鹽）

是有意義優於

$ hash = bcrypt（$ userpassphrase，$ salt）

給予管理/存儲$ pepper以及$ salt的額外負擔嗎？

我的假設是，hmac並沒有有意義地加強所得到的$ hash，並且存儲$ pepper的負擔超過了任何假設的好處......但我很想聽到知情的意見。

Answer 1

鍵控哈希或HMacs用於驗證數據的來源，而不是用於密碼保護。例如，如果您和我有一個共享密鑰，我可以將一些數據與計算的hmac一起發送給您，並且可以使用相同的密鑰來檢查hmac哈希值是否匹配，如果是，則知道數據來自我，並沒有被改變。

您無法有效地隱藏攻擊者無法訪問的計算機上的祕密密碼，您所要做的只是添加一層默默無聞的密碼。使用一個HMac，沒有共享密鑰，與SHA（$ userpassphrase，$ salt）基本相同，這非常容易計算，因此一旦「密鑰「密碼是已知的。

bcrypt的重點只是放慢散列過程，因此攻擊者需要很長時間才能爲您的鹽生成彩虹表。如果你想讓你的密碼哈希方案更安全，只需增加原始哈希函數的成本即可。在bcrypt中，您可以指定「logRounds」的數量（我認爲這就是他們稱之爲的），這是散列執行的次數。如果您指定15的logRounds（10是默認值），則散列將執行2^15 = 32768次，這會顯着降低散列速度。執行散列需要的時間越長，攻擊者需要花費的時間越長。

Answer 2

我不確定你想如何使用它。假設你存儲$ hash以後再進行質詢 - 響應認證，那麼你需要把$ pepper傳給客戶端，它就是另一種鹽。簡單地添加HMAC不會有太大用處。

Answer 3

把一個額外的散列加到像bcrypt這樣的密碼擴展函數上是沒有意義的;只需迭代幾次就會更容易，更好。

'胡椒'是一個常用但可疑的做法;我個人認爲，攻擊者獲取數據庫但不能訪問您的祕密密鑰的攻擊模型已經充分發揮作用，因此保護它們不值得實現複雜性。