我有一个基本的网络应用程序，它为系统的每个“租户”使用一个单独但相同的数据库。有一个主数据库，其中包含一个表，用于将每个用户链接到他们的数据库副本。
目前，我将所有租户数据库连接详细信息存储在主表中的纯文本中。我知道它不好，只是一个临时措施，所以我可以继续写功能。
我只能想到两种方法来保护连接细节（见下文），这两种方式都有缺陷，所以我希望得到一些建议，如果你不介意的话，请吗？
使用某种形式的salt和hash方法来存储密码，使用存储在应用程序本地文件中的密钥可以访问。
使用第三方服务（例如Amazon KMS）加密整个主数据库。
我假设的第二个选项是最安全的，但是我依赖于一个我不完全理解的DB插件和一个会降低性能的第三方服务。
我的两个问题是，如果某人能够将SELECT查询注入我的代码并访问主表（FYI，所有查询变量都被绑定为参数），它将始终解密密码而不管我用的是什么方法。这总是如此，我们接受的是什么，还是有另一层安全措施阻碍潜在的攻击者？
谢谢！
答案 0 :(得分：2)
好问题。不确定我有答案，但有一些注意事项：
首先考虑解决方案（1） - 密码哈希。
如果master数据库中存在SQL注入或类似漏洞，则不会导致解密密码。相反，它允许黑客获取密码的哈希值，他可以尝试通过暴力或相关攻击进行反转。如果你password hashing the wrong way，那么攻击者很可能会成功。另一方面，如果你使用像bcrypt（/ scrypt / argon2 / pbkdf2）这样具有良好参数的算法，那么你有更好的机会抵抗它。
此外，如果攻击者可以以某种方式将SQL查询注入您的主数据库，那么他也有可能不仅可以从中读取它而且还可以写入它（您可以通过使用读取查询来尝试降低此风险没有写访问权限的数据库帐户。如果攻击者可以写入，那么他可以用他选择的密码覆盖真实密码，所以无论如何他都会赢。
在第二个解决方案中，我相信您注意漏洞将被传递给第三方服务是正确的。在这种情况下，加密对您没有帮助。但是，如果您还正确地对密码进行哈希处理，则攻击者的方案将与方案（1）相同。因此，您从第三方服务获得的并不能减轻您的担忧。
所以一般来说，我说你绝对必须做解决方案（1）。然而，问题真的变成你还能做什么？这是一场长时间的谈话。一个简单的答案是双因素身份验证，但这可能会让用户感到烦恼。另一方面，只有当用户来自新的IP地址或新设备时才能考虑双因素身份验证，这将安全性与可用性要求结合起来。