每用户盐和跨用户哈希攻击答案

【问题标题】：Per user salts and cross-user hash attacks每用户盐和跨用户哈希攻击
【发布时间】：2013-03-21 12:35:51
【问题描述】：

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

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

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

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

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

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

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

【问题讨论】：

存储密码哈希的方式与 SQL 注入之间确实没有关系。使用加盐哈希的目的是使您的密码转储对攻击者无用。如果您允许攻击者执行任意 SQL，那么更改密码是您最不必担心的问题。

标签： security hash sql-server-2008-r2 passwords salt

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

您将任意 SQL 注入的风险视为任何密码安全性和/或应用程序安全性方面的障碍，这当然是正确的。

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

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

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

【讨论】：