SQL Server - 存储密码答案

【问题标题】：SQL Server - Storing PasswordSQL Server - 存储密码
【发布时间】：2014-04-30 22:14:28
【问题描述】：

我通常对存储敏感信息非常谨慎，并且更喜欢在可能的情况下使用 Facebook/Twitter 登录，以便他们处理密码。但是，我遇到了一个项目，除了在数据库中存储用户名/密码之外别无选择，我想确保我使用的代码在安全性方面完美无缺。

我已经编写了下面的过程，它将生成哈希密码并计划将@strPassword 和@strSalt 的结果存储在我的用户表中。

然后，网站/移动应用程序将对密码进行哈希处理，并通过 HTTPS 连接将其发布到 Web 服务，该服务会将哈希结果与盐相结合，并再次对其进行哈希处理，以将其与存储在我的表中的密码进行比较。

从我读到的内容来看，这应该防止彩虹表被用来解密它，以及使用 SHA512 来防止暴力破解，最后通过 HTTPS 来防止任何东西在传输过程中窃取密码。如果客户端设备上存在可以保存密码副本的病毒，则该病毒已经被部分散列了。

这里是否有任何潜在的缺陷或有更好的方法来实现这一点？

DECLARE @strPassword VARCHAR(128)
DECLARE @strSalt VARCHAR(36)
DECLARE @strHashMethod VARCHAR(10) = 'SHA2_512'

SET @strPassword = HASHBYTES(@strHashMethod, 'MyPassword')
SET @strSalt = CONVERT(VARCHAR(36), NEWID())
SET @strPassword = HASHBYTES(@strHashMethod, @strSalt + @strPassword)

SELECT CONVERT(VARBINARY(128), @strPassword)

【问题讨论】：

@strPassword 是用户的明文密码吗？
我很抱歉。当用户在内部系统（WinForms）上创建他们的帐户时，这个 sn-p 脚本运行。密码以纯文本形式传递到 SQL 中，然后使用 SHA_512 进行散列，结合盐，然后再次进行散列。任何地方都不会存储纯文本密码。
我明白了，我的意思只是确保您没有存储用户的纯文本密码。这将导致像 Target 最近经历的那样的黑客攻击。

标签： sql-server web-services security hash passwords

【解决方案1】：

对我来说看起来很安全！

如果您愿意，可以输入迭代计数，例如，在最后一行之前循环 100 次：

SET @strPassword = HASHBYTES(@strHashMethod, @strPassword)

或者，IC（迭代计数）可以是介于 100 和 1000 之间的随机整数，并与哈希密码和盐一起存储在基础表中。

使用 NEWID() 创建盐有点奇怪。我可能只使用 CRYPT_GEN_RANDOM(16)。

【讨论】：

您好，感谢 cmets！我会考虑一个迭代来多次散列它。我在 CRTYPT_GEN_RANDOM 上使用 NEWID 的原因是我需要支持 SQL 2005 到 2012。除非 SQL 2005 有更好的方法？
在我的回答中发现了轻微的异常：盐只会在第一次使用，并且不会在每次迭代中重新应用。如果您支持 SQL-2005，我认为 NEWID() 很有意义。优雅。