我们使用SHA2对用户密码进行哈希(在。net web应用程序中)&以下盐:
- 应用程序盐 -存储在数据库外部(在我们的例子中是web应用程序web)。配置为加密字符串)-这被传递给涉及登录，创建新用户和更改密码等的存储过程。
-
Per user salt -一个SQL唯一标识符-当前存储在用户表中-在插入时使用默认的
(CONVERT([char](36),newid(),(0)))自动生成 - 数据库盐 -存储在数据库设置表中的盐。
- 密码 -当然还有用户密码。
虽然这有助于彩虹&我在想，如果有人发现我们的安全漏洞，并设法对数据库运行更新语句，会发生什么?具体来说，是什么阻止用户用他们知道的密码注册我们的网站，然后替换密码?用他们的盐和哈希值对管理帐户进行哈希-从而使他们能够完全访问我们的站点/应用程序?
这是我们真正应该担心的风险吗?如果有，是否有技术术语/标准预防技术?
我正在考虑以某种方式将用户ID(在我们的情况下是整数)涉及到哈希中-只是好奇在这方面的最佳实践是什么，或者我们是否思考过多?
PS:我知道SHA2不是用于密码的理想散列，并且首选较慢的散列方法，如BCrypt，这是在我参与项目之前做出的决定
PS:我们的web应用程序(和它的应用程序密钥)与SQL服务器之间有很强的防火墙-它们之间只有一个端口是开放的&
老实说，我觉得你想得太多了。如果恶意用户能够对用户表运行更新查询，那么他们很可能对数据库中的其他表具有相同的访问权限。同样，最有可能的权限也存储在所述数据库中，并且运行另一个查询来授予自己适当的权限会更容易，而不是接管现有管理员的帐户。或者，直接在数据库中更改他们想要的任何数据，而完全忘记前端。
因此，我想说一旦用户访问了数据库(通过SQL注入或其他方式)，所有的赌注都已经取消了，他们可以做任何他们喜欢的事情。
注意，加盐散列的原因仅仅是为了使密码转储没有价值。也就是说，如果(当?)用户在另一个站点重复使用他们的密码并且没有加盐，那么在字典(所谓的彩虹表)中查找获得的散列值将提供明文密码，然后可以在另一个站点上使用该密码来冒充用户。加盐哈希消除了使用彩虹表查找值的"可逆性"。知道了盐确实给了攻击者一个优势，但他们仍然需要暴力破解来获得匹配的密码。添加一个未知的应用范围内的盐会使这一过程变得更加困难，尽管在数百万个账户和大量的蛮力或纯粹的运气的情况下，这仍然是可能的。
就任何密码安全和/或应用程序安全性而言，将任意SQL注入的风险考虑为一个阻碍因素，这当然是正确的。
在违反数据库安全的情况下(无论是有人窃取SQL转储还是对您的数据进行任意SELECT访问)，加强存储密码的预防措施可以保证最终用户的密码隐私，也可以保证一些应用程序的安全性，因为SELECT不会直接导致密码被盗并用于登录。
然而，如果SELECT语句是可访问的，它可以与其他SQL机制配对，例如，在服务器端编写任意web-shell或其他文件，这可能会允许攻击者以这种方式影响应用程序代码，他们可以在登录时MITM用户密码(因为加密是在服务器端进行哈希)。
你的问题的最终答案是，SQL注入是一个非常严重的问题，添加诸如web应用防火墙(waf)或SQL代理(想到GreenSQL)之类的层可以在没有适当SQL安全性的代码部署时提供优势。