緩存WCF服務內存中的明文密碼

Question

這可能聽起來像是一個可怕的想法乍一看，但這裏是我的情況：我有一個Windows服務，使用用戶名認證公開幾個WCF端點。自定義身份驗證器將在本地數據庫中查找用戶的憑據（密碼存儲爲鹽漬SHA-1），或者它將向另一個服務發出WCF請求以驗證密碼。 （在User對象上有一個枚舉，可以是Internal或External，指示使用哪個驗證源）。

我發現執行查找+哈希檢查或使WCF調用對我的服務的每個請求都很昂貴，所以我想緩存用戶名/密碼信息。緩存中的每個項目都有一個生命週期，例如，如果緩存中的項目的時間爲60秒，則在下一次請求時，身份驗證器將根據原始源代替緩存驗證憑據，然後進行更新。

對於本地數據庫，我可以簡單地將用戶名/ SHA1對存儲在字典中，並且在來自「內部」用戶的每個請求中，我只需重新提供散列提供的密碼並進行比較。對於「外部」用戶，我只會將明文密碼提交給驗證器，所以我將它放在哈希中並將其存儲爲緩存的一部分。儘管這肯定節省了數據庫請求或遠程服務調用的開銷，但我仍然必須每次都執行哈希操作。

有問題的服務將運行在具有良好物理和網絡安全性的內部服務器上。將明文密碼存儲在緩存中而不是存儲散列版本是否可接受？在這種情況下，我的風險似乎是攻擊者傾倒進程內存並獲取密碼。如果我認爲風險可以接受，是否還有其他原因，我應該避免在內存中使用明文密碼？

如果我選擇使用明文密碼，我認爲SecureString可以在一定程度上限制我的風險。使用SecureString（實現它看起來非常迂迴）是否值得遇到麻煩？我很清楚持久存儲密碼的風險，但我不確定共識似乎是什麼在易變的明文密碼存儲上。

Answer 1

SecureString使用加密的內存，所以這可能會提高每次執行散列時的性能。但是你必須在你的環境中進行配置。

至於在存儲器中存儲普通密碼的風險，這不是在這種情況下可以回答的問題。我只能說，是的。因爲這是出於各種原因適合我的情況。但那不會和你的一樣。

以下是我的建議： 考慮密碼泄漏的影響 - 基本上多少錢（$或$$$？）給黑客擁有密碼？目前大多數安全問題都來自財務激勵。相對而言，純粹的破壞行爲被這些傢伙拋棄了。

現在將其與以完全不同的方式（即SQL注入或打電話給用戶以「驗證他們的帳戶」）的安全性進行比較的可能性進行比較。如果幾個密碼的$值很高，並且沒有其他方法來獲取它們，那麼也許你應該繼續對它們進行加密（現在你已經證明了更強大的服務器的成本！）。並確保你保護密鑰 - 一旦黑客擁有你的服務器，這些密鑰就像程序存儲器一樣容易訪問。另一方面，如果價值低，並且還有其他可能的利用方式（通常存在），那麼可以合理地提出一個合理的觀點，認爲黑客的時間不利於服務器和轉儲記憶。

祝你好運。

Answer 2

有問題的服務將運行在具有良好物理和網絡安全性的內部服務器上。

只要從現在開始直到永恆（或下一個補丁，永遠都是第一個）都是正確的，將緩存的密碼存儲在內存中就像純文本一樣好。如果你將整個密碼數據庫存儲在ram中（比如說你的持久存儲速度太慢），我認爲將它們存儲爲安全字符串會更好，但由於你只能存儲多個密碼至多1分鐘，所以沒有問題。