我應該在哪裏以及如何存儲租戶數據庫密碼？

Question

我有一個基本的網絡應用程序，爲系統的每個「租戶」使用單獨但相同的DB。有一個主數據庫包含一個將每個用戶鏈接到他們的數據庫副本的表。

目前，我已將所有租戶數據庫連接詳細信息以明文形式存儲在主表中。我知道它不好，只是一個臨時措施，所以我可以繼續編寫功能。

我只能想到兩種方法來確保連接細節（見下文），這兩種方法似乎有缺陷，所以我希望得到一些建議，如果你不介意的話，請嗎？

1. 使用某種形式的鹽和散列方法來存儲密碼，與存儲在應用程序的本地文件的密鑰訪問。

2. 使用第三方服務（如Amazon KMS）加密整個主數據庫。

我認爲第二個選項是最安全的，但後來我在一個數據庫插件，我不完全理解和第三方服務，這會降低性能的依賴。

這兩個問題我的問題是，如果有人能夠將SELECT查詢插入我的代碼並訪問主表（所有查詢變量都綁定爲參數），它將始終解密密碼我用什麼方法。這是否總是這樣，我們只是接受，還是有另一層安全來阻擋潛在的攻擊者？

謝謝！

Answer 1

好問題。不知道我有答案，但有一些注意事項：

首先考慮解決方案（1） - 密碼散列。

如果主數據庫中存在SQL注入漏洞或類似漏洞，則不會導致解密密碼。相反，它允許黑客獲得密碼的散列，他可以嘗試通過強力或相關攻擊進行反轉。如果你做password hashing the wrong way，那麼攻擊者很可能會成功。另一方面，如果您使用像參數bcrypt（/ scrypt/argon2/pbkdf2）這樣的算法，那麼您有更好的機會抵制它。另外，如果攻擊者可以以某種方式將SQL查詢插入到主數據庫中，那麼也有可能他不僅可以讀取它，而且還可以寫入它（您可以嘗試通過使用讀取查詢來緩解這種風險與一個沒有寫訪問權限的數據庫帳戶）。如果攻擊者可以寫信給他，那麼他可以用自己選擇的密碼覆蓋真正的密碼，所以他贏了。

看看第二個解決方案，我相信你是正確的，一個注入漏洞只會傳遞給第三方服務。在這種情況下，加密不會幫助你。但是，如果您也正確地對密碼進行哈希處理，則攻擊者的情況與情形（1）相同。因此，您從第三方服務中獲得的東西並不能減輕您的擔憂。

所以我一般說你絕對要做解決方案（1）。然而，這個問題真的成爲你能做更多的事情嗎？這是一個長時間的談話。一個簡單的答案是雙因素認證，但這可能會讓用戶感到煩惱。另一方面，只有當用戶來自新IP地址或新設備時，您纔可以考慮使用雙因素身份驗證，該設備將安全性與可用性要求相結合。