我应该在哪里以及如何存储租户数据库密码？

Question

我有一个基本的网络应用程序，为系统的每个“租户”使用单独但相同的DB。有一个主数据库包含一个将每个用户链接到他们的数据库副本的表。

目前，我已将所有租户数据库连接详细信息以明文形式存储在主表中。我知道它不好，只是一个临时措施，所以我可以继续编写功能。

我只能想到两种方法来确保连接细节（见下文），这两种方法似乎有缺陷，所以我希望得到一些建议，如果你不介意的话，请吗？

1. 使用某种形式的盐和散列方法来存储密码，与存储在应用程序的本地文件的密钥访问。

2. 使用第三方服务（如Amazon KMS）加密整个主数据库。

我认为第二个选项是最安全的，但后来我在一个数据库插件，我不完全理解和第三方服务，这会降低性能的依赖。

这两个问题我的问题是，如果有人能够将SELECT查询插入我的代码并访问主表（所有查询变量都绑定为参数），它将始终解密密码我用什么方法。这是否总是这样，我们只是接受，还是有另一层安全来阻挡潜在的攻击者？

谢谢！

Answer 1

好问题。不知道我有答案，但有一些注意事项：

首先考虑解决方案（1） - 密码散列。

如果主数据库中存在SQL注入漏洞或类似漏洞，则不会导致解密密码。相反，它允许黑客获得密码的散列，他可以尝试通过强力或相关攻击进行反转。如果你做password hashing the wrong way，那么攻击者很可能会成功。另一方面，如果您使用像参数bcrypt（/ scrypt/argon2/pbkdf2）这样的算法，那么您有更好的机会抵制它。另外，如果攻击者可以以某种方式将SQL查询插入到主数据库中，那么也有可能他不仅可以读取它，而且还可以写入它（您可以尝试通过使用读取查询来缓解这种风险与一个没有写访问权限的数据库帐户）。如果攻击者可以写信给他，那么他可以用自己选择的密码覆盖真正的密码，所以他赢了。

看看第二个解决方案，我相信你是正确的，一个注入漏洞只会传递给第三方服务。在这种情况下，加密不会帮助你。但是，如果您也正确地对密码进行哈希处理，则攻击者的情况与情形（1）相同。因此，您从第三方服务中获得的东西并不能减轻您的担忧。

所以我一般说你绝对要做解决方案（1）。然而，这个问题真的成为你能做更多的事情吗？这是一个长时间的谈话。一个简单的答案是双因素认证，但这可能会让用户感到烦恼。另一方面，只有当用户来自新IP地址或新设备时，您才可以考虑使用双因素身份验证，该设备将安全性与可用性要求相结合。