每用戶鹽和跨用戶哈希攻擊

Question

我們哈希用戶的密碼（在.NET Web應用程序）與SHA2 &以下鹽：

• 應用鹽 - 存儲在數據庫之外（在我們的例子作爲加密字符串的Web應用程序web.config） - 將其傳遞到參與登錄，創建新用戶和更改密碼等存儲過程中。
• 每個用戶salt - SQL uniqueidentifier - 當前存儲在用戶表 - 在插入時使用缺省值012自動生成
• 數據庫鹽 - 存儲在數據庫內的設置表中的鹽。
• 密碼 - 當然還有用戶密碼。

雖然這有助於彩虹&字典攻擊等我在想，如果有人確實發現在我們的安全孔和管理，以對數據庫運行的更新語句會發生什麼 - 特別是 - 什麼會從停止用戶使用他們知道的密碼在我們的網站註冊，然後用管理帳戶中的salt和hash替換鹽&哈希 - 從而使他們可以完全訪問我們的網站/應用程序？

這是我們應該真正擔心的風險嗎？如果是這樣，它是否有技術術語/標準預防技術？

我在想以某種方式將用戶ID（在我們的例子中是一個整數）包含在哈希中 - 只是好奇最好的做法是在這個還是我們過度思考？

PS：我知道SHA2心不是一個理想的哈希使用密碼和較慢的哈希方法，如BCrypt是首選，這是我在參與項目之前做了一個決定

PS：我們Web應用程序（及其應用程序密鑰）從SQL服務器嚴重防火牆 - 它們之間只有一個端口是開放的&用於SQL）

Answer 1

老實說，我認爲你是過度思考的東西。如果惡意用戶能夠對用戶表運行更新查詢，則他們很可能擁有對數據庫中其他表的平等訪問權限。同樣，最有可能的權限也存儲在所述數據庫中，並且運行另一個查詢以授予他們自己適當的權限，而不是輕易接管現有的管理員帳戶會更容易。或者，只需在數據庫中直接更改他們想要的任何數據，並完全忘記前端。

因此，我想說，一旦用戶有權訪問數據庫（通過SQL注入或其他方式），所有投注已經關閉，他們可以做任何他們喜歡的事情。

注意醃製散列的原因僅僅是爲了使密碼轉儲無價值。也就是說，如果（當？）用戶將密碼重新用於另一個站點並且它不被鹽漬時，在字典（所謂的彩虹表）中查找獲得的散列值將提供明文密碼，這可能然後在另一個網站上使用來冒充用戶。醃製散列消除了使用彩虹表查找價值的這種「可逆性」。知道鹽確實會給攻擊者一條腿，但他們仍然需要蠻橫的方式來獲得匹配的密碼。添加一個未知的應用程序範圍內的鹽使得這個過程變得更加困難，儘管它仍然有可能擁有數百萬的帳戶和大量的暴力或純粹的運氣。

Answer 2

在任何密碼安全性和/或應用程序安全性方面，考慮到任意SQL注入作爲展示瓶頸的風險當然是正確的。

在違反數據庫安全性（通過某人竊取SQL轉儲或對您的數據進行任意SELECT訪問時），強化存儲密碼的預防性措施可以保證關於最終用戶密碼的私密性和還有一些應用程序安全性，因爲SELECT不會直接導致可以被盜用並用於登錄的密碼。但是，如果可以訪問SELECT語句，那麼可以將其與其他SQL機制配對，以便例如編寫任意Web-Shell或服務器端的其他文件，以便潛在地允許攻擊者影響此類應用程序代碼一種他們可以在登錄時MITM用戶密碼的方式（因爲密碼在服務器端發生散列）。

你的問題的最終答案是，SQL注入是一個非常增加層數，如Web應用防火牆（Web應用防火牆）或SQL代理（GreenSQL的想到的）可以提供一個優勢，當代碼部署嚴重的問題，沒有適當的SQL安全性。