正在通過電纜發送哈希密碼的安全漏洞？

Question

我遇到了一家公司正在使用的系統，我們正在考慮與一家中型（對我們而不是他們）項目合作。

他們有一個我們需要整合的web服務。

我目前對正確的用戶名/密碼管理的理解是，用戶名可以作爲明文存儲在數據庫中。每個用戶應該有一個獨特的僞隨機鹽，它也可以以明文形式存儲。它們的密碼文本必須與鹽級聯，然後可將此組合字符串散列並存儲在數據庫的nvarchar字段中。只要密碼通過SSL提交給網站（或網絡服務），一切都應該是可愛的。

如果我錯了，隨意翻閱我的理解，如上所述。

無論如何，回到手頭的話題。這個潛在的合作伙伴運行的WebService不接受我期望的用戶名和密碼。它接受兩個名爲'Username'和'PasswordHash'的字符串字段。我給出的'PasswordHash'值確實看起來像一個散列，而不僅僅是一個錯誤密碼字段的值。

這是爲我提高紅旗。我不確定爲什麼，但由於某種原因，我覺得通過電線發送散列密碼會感到不舒服。關於我的頭頂，我無法想到這將是一件壞事的原因......從技術上講，無論如何，數據庫中都有散列。但它讓我感到緊張，而且我不確定是否有這個原因，或者我只是偏執狂。

編輯

我被一些評論困惑下面，直到我重新閱讀我的文章。

原來，我有一句「只要密碼通過明文提交給網站（或網絡服務），一切都應該是可愛的。」

我發誓，因爲我以爲我在想'SSL'這個詞。出於某種原因，我輸入了「明文」這個詞。哇。

最差。錯字。永遠。

Answer 1

使用散列密碼將其發送到服務沒有價值，因爲您仍然需要單獨的機制來保護通信，SSL

如果系統接受散列密碼，對於所有意圖和目的，散列密碼是的密碼。如果攻擊者獲得哈希密碼，他可以訪問該帳戶，而無需計算出原始密碼。

上述所有問題的一個重要問題是，如果數據庫受到攻擊&攻擊者獲取哈希密碼，這意味着通過所述WebService即時訪問所有帳戶，因爲就WebService而言，密碼。

我真的建議你把它帶給他們&說說吧。這可能是某些開發人員沒有獲得關注/優先考慮的事情之一。

Answer 2

當涉及到安全性時，它很好是偏執狂，但在這種情況下，我不認爲你有太多擔心。哈希是嚴格的一種方式，所以永遠不能轉換回明文密碼。接收方將只檢查發送的散列值是否與他們存儲的散列值相匹配。

唯一的問題是確保在傳輸過程中沒有人可以竊聽散列密碼，所以應該使用像SSL這樣的東西。如果有人在傳輸中嗅探用戶名+散列密碼，攻擊者可能會重用它。

Answer 3

細節不談，這是一個容易回答的問題：

你可以讓所有的努力在世界上，但如果你沒有使用SSL，您的驗證過程可以輕輕鬆鬆被利用。