我开始编写我的第一个严肃的 Web 应用程序，并且正在考虑如何存储用户名和密码信息。有很多文章详细说明了存储纯文本密码是一个非常糟糕的主意，而加盐加密密码是要走的路。但是，我几乎找不到关于限制对用户数据本身的访问的信息。
我正在考虑一种情况，即我的 Web 应用程序遭到入侵，攻击者可以从我的数据库中读取任何信息。即使我使用加密密码存储用户名，攻击者也能够从数据库中提取所有用户名（但至少他们不会得到密码）。但是，我可以限制访问，因此即使我的应用程序也无权访问这些数据。我正在考虑阻止我的数据库用户使用用户名和密码查看表。然后，您可以通过获取用户名和密码的存储过程授予访问权限 - 如果找到带有密码的用户名，则返回 true，或者显示散列用户名和密码的视图，因此即使受到损害，也无法找到真实的用户名.
鉴于我是新手，而且我找不到任何推荐类似内容的文章，我猜我错过了一些简单的东西，使上述想法不安全。
谢谢。
从安全的角度来看，威胁是当底层存储以任何方式暴露时会发生什么，而不仅仅是 sql 注入select * from users;语句。你信任你的管理员吗？即使是你不得不放手的那个？还有谁可以进入盒子？它是第三方公司的虚拟机吗？在云端？这就是为什么通常首先强调获得哈希权的原因，以便用户密码即使对授权用户也有一定的防御能力。
也就是说，我认为通过视图控制访问是有益的，这样您就只能从您的网络的角度执行伪指令“插入用户”、“删除用户”、“用户是否存在”和“这些凭据是否有效”应用程序。这可以防止枚举，除非重复调用具有已知用户标识符的数据库，这比允许攻击者获取整个数据库要好。在您的代码或框架中存在任何潜在危害/不可预见的漏洞的情况下，您正在降低攻击者获取该表的难易程度。唯一的问题是与现有框架的兼容性，尽管许多框架提供了扩展或实现自定义身份验证后端的能力。
关于散列，使用PBKDF2或bcrypt或等效的带盐的慢速散列密钥派生函数，而不仅仅是带盐的散列。一篇关于该主题的体面文章将解释这个阶段（有时他们建议将哈希重复数千次迭代；这本质上是相同的想法）。
我可以说不要轻率并冒险拒绝投票吗？
避免您的用户名和密码被黑客入侵的最佳方法。首先不要存储它们。
使用联合身份验证，例如 Facebook Connect (oAuth) 或 Google Open-ID。我在这里写更多的好处。