1

我们使用 SHA2 和以下盐对用户密码（在 .net Web 应用程序中）进行哈希处理：

  • 应用程序 salt - 存储在数据库之外（在我们的例子中，Web 应用程序 web.config 作为加密字符串） - 这被传递给涉及登录、创建新用户和更改密码等的存储过程。
  • 每个用户 salt - 一个 SQL 唯一标识符 - 当前存储在用户表中 - 在插入时使用默认值自动生成(CONVERT([char](36),newid(),(0)))
  • 数据库盐- 存储在数据库中的设置表中的盐。
  • 密码- 当然还有用户密码。

虽然这有助于彩虹和字典攻击等，但我在想如果有人确实发现我们的安全漏洞并设法对数据库运行更新语句会发生什么 - 特别是 - 什么会阻止用户使用我们的网站注册他们知道的密码，然后用他们的盐和散列替换管理员帐户上的盐和散列 - 从而让他们对我们的站点/应用程序具有完全的管理员访问权限？

这是我们应该真正担心的风险吗？如果有，是否有技术术语/标准预防技术？

我正在考虑以某种方式将用户 ID（在我们的例子中是一个整数）包含在哈希中 - 只是好奇这方面的最佳实践是什么，或者我们是否过度思考？

PS：我知道 SHA2 不是用于密码的理想哈希，并且首选 BCrypt 等较慢的哈希方法，这是我参与该项目之前做出的决定

PS：我们的 Web 应用程序（及其应用程序密钥）受到 SQL 服务器的严格防火墙 - 它们之间只有一个端口是开放的，并且用于 SQL）

4

2 回答 2

4

老实说，我认为你是在想太多的事情。如果恶意用户能够对您的 users 表运行更新查询，则他们很可能对数据库中的其他表具有相同的访问权限。同样，最有可能的权限也存储在所述数据库中，并且运行另一个查询以授予自己适当的权限会更容易，而不是接管现有管理员的帐户。或者，只需直接在数据库中更改他们想要的任何数据，而完全忘记前端。

因此，我想说一旦用户可以访问数据库（通过 SQL 注入或其他方式），所有的赌注都已经结束，他们可以做任何他们喜欢的事情。

请注意，对哈希进行加盐处理的原因仅仅是为了使密码转储变得毫无价值。也就是说，如果（何时？）用户将他们的密码重新用于另一个站点并且没有加盐，则在字典（所谓的彩虹表）中查找获得的散列值将提供明文密码，然后可以在另一个网站上用于冒充用户。加盐哈希消除了使用彩虹表查找值的这种“可逆性”。知道盐确实让攻击者占了上风，但他们仍然需要暴力破解才能获得匹配的密码。添加一个未知的应用程序范围的盐会使这个过程变得更加困难，尽管它仍然可以使用数百万个帐户和大量的蛮力或纯粹的运气。

于 2013-03-21T12:42:42.853 回答
0

就任何密码安全性和/或应用程序安全性而言，将任意 SQL 注入的风险视为阻碍因素，您当然是正确的。

在违反数据库安全的情况下（有人窃取 SQL 转储或对您的数据进行任意 SELECT 访问），强化存储密码的预防措施可以保证最终用户的密码隐私以及某些应用程序安全性因为 SELECT 不会直接导致可以被盗并用于登录的密码。

但是，如果 SELECT 语句是可访问的，则可以与其他 SQL 机制配对，例如，在服务器端编写任意 Web-shell 或其他文件，这可能允许攻击者以他们可能的方式影响应用程序代码MITM 登录时的用户密码（因为加密发生在服务器端的散列）。

您的问题的最终答案是，SQL 注入是一个非常严重的问题，并且在没有适当 SQL 安全性的情况下部署代码时，添加 Web 应用程序防火墙 (WAF) 或 SQL 代理（想到 GreenSQL）等层可以提供优势。

于 2013-03-21T13:38:58.630 回答