密碼，鹽，散列，DB：第一百萬次

我知道這個話題已經被討論了一百萬次。但這對我來說是新的，我對它的瞭解越多，我越瞭解實際發生或應該發生的事情。密碼，鹽，散列，DB：第一百萬次

我將每個用戶的salt添加到用戶密碼的哈希存儲中，因此存儲的密碼哈希如下所示：hash（password + perusersalt）。這會導致不同用戶的相同密碼被存儲爲數據庫中的不同字符串。涼。但我並不擔心有人闖入數據庫並查找哈希密碼。我很擔心有人蠻橫查詢我的服務器的用戶名和密碼的組合。在這種情況下，密碼的醃製和散列存儲是無用的，因爲用戶名和密碼的正確組合將產生成功的登錄。對？

我的印象是，在這種情況下鹽是相當無用的嗎？因爲服務器只在接口上接受用戶名和密碼（不發送鹽），所以普通的字典攻擊就可以了，對吧？

所以salt只能從有權訪問數據庫的人那裏混淆用戶的密碼（只能通過反向彩虹表查找獲得）。嗯。

相關：我的網絡應用程序甚至不傳輸簡單的密碼。密碼已經散佈在客戶端，只是完全拒絕對某人被盜密碼的責任，整個事情使用SSL。

這是否意味着我或多或少處於可能的最高安全級別，因爲用戶名和密碼的正確組合必須產生成功登錄？

謝謝你清理我腦海中的混亂。

來源

2012-02-14 Yanone

你對暴力攻擊的假設是正確的。如果用戶有一個簡單的密碼，那麼salt和hash並不重要。字典攻擊會猜測「密碼」並允許攻擊者進入。您必須要求用戶提供安全密碼，然後進行單向加密（使用salt進行哈希），然後像您一樣使用SSL。

來源

2012-02-14 21:09:49 thepriebe

如果你控制網頁前端，你可以人爲地限制每分鐘可以嘗試的密碼數量，並添加一個驗證碼圖像，其他網站如hotmail使用後會嘗試減慢速度。 – David 2012-02-14 21:12:27

取決於RDBMS解決方案，即使您不控制等式的網絡邊，通常也可以控制此方法，但是如果您決定切換到新的DB，它很可能不會很便攜。 – 2012-02-14 21:21:13

你也可以使用bcrypt，這是專門設計的慢，無論你的服務器速度如何，都會讓暴力破解速度變慢。 – 2012-02-14 21:26:46

「密碼讓客戶端哈哈哈拒絕了某人被盜密碼的責任，整個事情都使用SSL。」

客戶端發送哈希（密碼+鹽）嗎？

通過這種設計，客戶端並不需要密碼才能成功登錄，只需要哈希。所以你可能仍然要負責泄漏真實密碼（哈希）。

來源

2012-02-14 23:11:53 ysdx

客戶端發送一個沒有任何salt的散列密碼，與數據庫中salt存儲的內容無關。傳輸通過SSL進行保護。拒絕承擔責任意味着我的同一用戶擁有相同密碼的哈希密碼帳戶無法在其他地方開放，向用戶提供服務並增加他的隱私，並且我永遠不會因爲我從未收到用戶的明確密碼而被指責做錯。他們。這對我的系統來說並沒有增加安全性（也沒有減少），但非常酷。 – Yanone 2012-02-15 00:28:36

更酷：當客戶端已經傳輸哈希（hardwiredsalt + plainpassword）時，隨時可用的彩虹表會失敗。在我的項目中使用的散列方法當然可以在JavaScript中看到（在這種情況下是SHA-256），這可以避免使用相同的方法巧妙地與其他站點發生散列衝突。 – Yanone 2012-02-15 00:34:40

密碼，鹽，散列，DB：第一百萬次

回答

相關問題