为什么我们不使用一个专门用于身份验证的数据库，而另一个用于其他的数据库呢?

清理输入和保护密码是有区别的。SQL注入可以发生在任何查询中，并且允许某人不仅窃取数据，而且破坏数据。任何时候都应该防止这种情况发生。

对于用户名和密码，需要采取附加措施。首先，根本不要存储密码，而是始终存储散列版本，用salt进行散列。此外，如果您愿意，还可以将身份验证放在不同的数据库中，甚至可以放在一些身份验证服务中，但就像我说的，这是额外的。

当然，如果你有一大堆从网站的角度来看是只读的数据，你可能会把它们存储在另一个数据库中，或者至少让网站使用一个没有任何权限修改数据的数据库用户进行连接。这样可以更好地保护数据不被破坏，因为网站错误、SQL注入甚至用户名和密码泄露都不会导致数据被破坏。但这也适用于作为"不太重要"数据的用户凭据。

你似乎漏掉了两点:

• 你的其他数据也应该是安全的(否则没有必要保护应用程序)
• 你不存储密码。从来没有。您只存储由密码、用户名(可选)和特定于记录的盐构建的散列。所以保护这个基础不是很重要，它只是为了防止冒充

由于没有理由以更大的方式保护DB的一部分，只是确保整个数据库得到正确保护，因此管理一个DB比管理两个TB要容易得多。试图在不同的RDBMS中保存不同类型的数据并保持它们的一致性是一场噩梦。

最后，请注意，这不会改变任何关于mysql注入。只是不要使用准备好的语句来允许这些注入。

这是个很难回答的问题。实际上，您可以有两个数据库，一个用于实际数据，另一个用于"提供"。

让我们这么说吧:即使你使用一个数据库只是为了"装饰"，如果这个数据库被黑客入侵了会发生什么?你的用户会看到"这个网站被黑了"还是…?:)

编辑:什么是保护?保护是当你买了一杯咖啡，你不想让你的朋友或别人喝它。那么如果你买了一杯咖啡和一个松饼呢?你会只保护一个人吗?你会保护两者吗?哪一个对你来说更重要?如果你像我和大多数人一样，你会说两者都有。你的评论让我明白，松饼(用户)比其他东西(家具)更重要。

如果你不关心咖啡，你为什么需要保护?可能是因为你对咖啡的重视程度还不足以保护它。那么让我这么说:你用来买咖啡的钱在还是钱的时候是有价值的，但现在它们是咖啡了，除了它们的形状之外，还有什么变化呢?没有。

现在让我们回到我们的例子:如果你有一个简单的数据库，它只包含"装饰"文本，如"TITLE"，"DESCRIPTION"等。丢了它们不坏吗?你不用去那儿修吗?难道你不需要努力把一切都弄得漂亮吗?

更不用说与数据库相关的大多数漏洞可能比仅仅丢失一个数据库更糟糕。sql注入问题可能会破坏所有数据库，这是您试图避免的危险。因此，试图确保一个数据库比另一个数据库更安全几乎是没有意义的。试着保护所有的东西，你会确信无论你走到哪里，什么都不会发生。所以你害怕一个特殊的囚犯，你把他关得严严实实，把那间旧牢房关得严严实实。你把目光移开，原来牢房里的犯人现在已经出来了!更糟糕的是，他释放了那个特殊囚犯(以及其他所有人)。这就是sql注入隐含的安全漏洞。

我认为你需要更深入地研究你的RDBMS保护层，以更好地了解为什么它们在同一实例中更好。

让我们以MySQL数据库为例:

• 一个实例由3个以上的数据库组成(mysql, information_schema，以及你创建的所有其他数据库)。
• 所以你已经有一个单独的数据库repo来处理auth + user + pass -那就是你的MySQL数据库。

有很多方法可以开发不受黑客攻击的应用程序——当使用MySQL时，大多数程序员使用开放SQL代码(内联SQL)——这就是问题所在——黑客会利用这一点!要解决这个问题，请使用存储过程(封装)。

数据库内部权限也是一个问题——懒惰的开发人员或愚蠢的DBA会给应用程序用户额外的权限。从许多方面来看，你的想法都是多余的。更多的实例将花费你更多的钱，更多的资源，等等。