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

Question

我们使用SHA2＆amp ;;哈希用户密码（在.net Web应用程序中）以下盐类：

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

虽然这有助于彩虹＆amp;字典攻击等我想到如果有人确实在我们的安全性中发现漏洞并设法对数据库运行更新语句会发生什么 - 具体来说 - 什么会阻止用户使用他们知道的密码注册我们的网站然后更换盐与盐使用salt和hash在管理员帐户上哈希 - 从而为他们提供对我们网站/应用程序的完全管理员访问权限？

这是否是我们应该实际担心的风险？如果是这样，它是否有技术术语/标准预防技术？

我在考虑以某种方式在哈希中涉及用户ID（在我们的例子中是一个整数） - 只是好奇最好的做法是什么，或者我们是不是在考虑事情？

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

PS：我们的网络应用程序（及其应用程序密钥）受到SQL服务器的大量防火墙控制 - 它们之间只打开一个端口。那用于SQL）

Answer 1

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

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

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

Answer 2

考虑到任意密码安全性和/或应用程序安全性方面的任意SQL注入风险，你肯定是正确的。

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

但是，如果可以访问SELECT语句，那么可以与其他SQL机制配对，例如，编写任意Web-shell或服务器端的其他文件，这可能会让攻击者在这样的情况下影响应用程序代码。他们可以在登录时MITM用户密码（因为加密是在服务器端进行散列）。

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