为什么我们没有一个特定的数据库只用于身份验证而另一个用于其他数据库？

Question

我想知道为什么拥有一个数据库服务更简单，更安全，专门用于用户身份验证（扣留用户名和密码），这些服务可以很好地保护（输入已经过消毒等等）。

另一个数据库服务，用于网站中的所有其他数据，可能不太安全，可用于提供网络内容。

这不是防止这些天发生大量SQL注入的好方法吗？

Answer 1

你似乎错过了两点：

• 您的其他数据也应该是安全的（否则没有必要保护应用程序）
• 您不存储密码。决不。您只存储根据密码，用户名（可选）和记录特定盐构建的哈希。因此，保护​​这个基础并不是那么重要，只有这样才能防止冒充

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

最后，请注意，这不应该改变与mysql注入有关的任何内容。不要使用准备好的陈述来禁止这些注射。

Answer 2

没有。清理输入和保护密码之间存在差异。 SQL注入可以在任何查询中发生，并且不仅允许某人窃取，还允许销毁数据。应该始终防止这种情况。

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

当然，如果你从网站的角度看到一大堆只读数据，你可以将它存储在不同的数据库中，或至少使用没有任何数据库的数据库用户连接网站。修改数据的权利。这样，数据可以更好地防止破坏，因为网站上的错误，SQL注入甚至泄漏用户名和密码都不会导致数据被破坏。但这也是用户凭证作为“不太重要”的数据。

Answer 3

这是一个棘手的问题。实际上，你可以拥有两个数据库，一个用于合理的数据，另一个用于＆＃34;装饰＆＃34;。

让我们这样说吧：即使您仅使用数据库来提供＆＃34;装备＆＃34;，如果该数据库被黑客攻击会怎样？您的用户是否必须看到＆＃34;此网站已被删除＆＃34;在该部分还是......？ ：）

编辑：什么是保护？保护就是当你买咖啡而你不想让你的朋友或某人喝咖啡时。如果你买咖啡和松饼怎么办？你会保护一个吗？你会保护两者吗？哪一个对你更重要？如果你喜欢我和大多数人，你会同时说两个。你让我理解的是，松饼（用户）比其他东西（装饰）更重要。

如果你不关心咖啡，你为什么需要保护？可能是因为你并没有真正重视咖啡以保护咖啡。然后让我这样说：你用来买咖​​啡的钱在他们还是钱的时候是值得的，但现在他们喝咖啡了，他们的形状有什么变化？什么都没有。

现在让我们回到我们的案例：如果你有一个简单的数据库只包含＆＃34;装饰＆＃34;文字如＆＃34; TITLE＆＃34;，＆＃34; DESCRIPTION＆＃34;等他们失败并不是很糟糕？不是你必须去那里修理它们吗？你不得不努力让一切变得漂亮吗？

不要说大多数与数据库相关的漏洞可能比只丢失一个数据库更糟糕。有一个SQL注入问题可能会导致所有数据库被破坏，这是您试图避免的危险。因此，尝试更多地保护数据库几乎毫无意义。试着确保一切安全，你确定无论你走到哪里都不会发生任何事情。 所以你害怕一个特殊的囚犯，你确保他很多，并且把那个老牢房弄得一团糟。你看向别处，老牢房里的囚犯现在离开他的牢房！更糟糕的是，他释放了特殊犯人（以及其他所有人）。这是sql注入所暗示的那种安全漏洞。

Answer 4

我认为您需要深入了解您的RDBMS保护层，以便更好地了解它们在同一实例中的优势。

我们以MySQL数据库为例：

• 实例由3 +数据库（mysql，information_schema和您创建的所有其他数据库）组成。
• 所以你已经有了一个单独的数据库仓库来处理auth + user + pass - 那就是你的MySQL数据库。

有很多方法可以开发无黑客的应用程序 - 当使用MySQL时，大多数编码器都使用开放的SQL代码（内联SQL） - 这就是问题 - 黑客会利用这一点！要修复此使用存储过程（封装）。

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