在数据库中存储密码的首选方法/数据类型是什么（最好是 SQL Server 2005）。我在我们的几个应用程序中一直这样做的方式是首先使用 .NET 加密库，然后将它们作为二进制 (16) 存储在数据库中。这是首选方法还是我应该使用不同的数据类型或分配超过 16 个的空间？
【问题讨论】：
标签： sql-server database security encryption passwords
我将与密码等效的加盐哈希值存储在数据库中，而不是密码本身，然后始终将哈希值与生成的用户传入的哈希值进行比较。
将文字密码数据存储在任何地方都太危险了。这使得恢复变得不可能，但是当有人忘记或丢失密码时，您可以通过一些检查并创建一个新密码。
【讨论】：
varchar 数据库列中。他们的最后一点好的想法是定义他们的哈希字符串的格式，其中盐包含在字符串中。
首选方法：永远不要将密码存储在您的数据库中。只有哈希值。加盐调味。
【讨论】：
我做的和你描述的一样，只是它被存储为一个字符串。我对加密的二进制值进行 Base64 编码。要分配的空间量取决于加密算法/密码强度。
我认为你做得对（假设你使用了Salt）。
【讨论】：
通过这些措施，您的用户密码将得到很好的保护，以防止：
【讨论】：
由于哈希函数的结果是 0 到 255（或 -128 到 127，取决于 8 位数据类型的符号）范围内的一系列字节，因此将其存储为原始二进制字段可以最有意义，因为它是最紧凑的表示，不需要额外的编码和解码步骤。
某些数据库或驱动程序对二进制数据类型没有很好的支持，或者有时开发人员对它们还不够熟悉，感觉不太舒服。在这种情况下，使用像 Base-64 或 Base-85 这样的二进制到文本编码，并将生成的文本存储在字符字段中是可以接受的。
所需字段的大小由您使用的散列函数决定。 MD5 总是输出 16 个字节，SHA-1 总是输出 20 个字节。一旦您选择了一个哈希函数，您通常会被它所困扰，因为更改需要重置所有现有密码。因此，使用可变大小的字段不会给您带来任何好处。
关于执行散列的“最佳”方式，我已尝试为有关该主题的其他 SO 问题提供许多答案：
【讨论】：
我使用用户名的 sha 哈希、Web 配置中的 guid 和密码，存储为 varchar(40)。如果他们想暴力破解/字典，他们还需要破解 guid 的 Web 服务器。如果用户名确实找到了密码，则会在整个数据库中创建彩虹表。如果用户想更改他们的用户名，我只是同时重置密码。
System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(
username.ToLower().Trim(),
ConfigurationManager.AppSettings("salt"),
password
);
【讨论】：
密码的简单哈希，甚至（盐+密码）通常是不够的。
见：
和
http://gom-jabbar.org/articles/2008/12/03/why-you-should-use-bcrypt-to-store-your-passwords
两者都推荐 bcrypt 算法。可以在线找到大多数流行语言的免费实现。
【讨论】：
您可以在数据库中使用多个哈希值，这只需要一点额外的努力。但是，如果您认为将来极有可能需要支持其他格式，那么这是非常值得的。我会经常使用像
这样的密码条目{hashId}${salt}${哈希密码}
其中“hashId”只是我在内部使用的一些数字来识别它，例如，我正在使用具有特定哈希模式的 SHA1； "salt" 是 base64 编码的随机盐； “散列密码”是一个 base64 编码的散列。如果您需要迁移哈希，您可以拦截使用旧密码格式的人，并让他们在下次登录时更改密码。
正如其他人提到的那样，您要小心使用哈希值，因为很容易做一些不太安全的事情，例如，H(salt,password) 远比 H(password,salt) 弱，但同时您希望在为此付出的努力与网站内容的价值之间取得平衡。我会经常使用 H(H(password,salt),password)。
最后，与能够使用需要文本数据的各种工具的好处相比，使用 base64 编码密码的成本适中。是的，它们应该更灵活，但是您准备好告诉您的老板他不能使用他最喜欢的第三方工具，因为您想为每条记录节省几个字节吗？ :-)
编辑添加另一条评论：如果我建议故意使用一种算法，该算法甚至会烧掉每个密码的 1/10 秒散列，我会很幸运被我老板的办公室嘲笑。 （没那么幸运？他会记下一些东西在我的下一次年度审查中讨论。）当你有几十个甚至几百个用户时，浪费时间不是问题。如果您要推送 10 万用户，通常会有多人同时登录。你需要快速而强大的东西，而不是缓慢而强大的东西。 “但是信用卡信息呢？”充其量是虚伪的，因为存储的信用卡信息不应该在您的常规数据库附近，并且无论如何都会被应用程序加密，而不是个人用户。
【讨论】：
如果您使用 ASP.Net，您可以使用内置的会员 API。
它支持多种类型的存储选项，包括；一种方式哈希，两种方式加密，md5 + salt。 http://www.asp.net/learn/security 了解更多信息。
如果您不需要太花哨的东西，这对网站来说非常有用。
如果你不使用 ASP.Net，这里是 4guys 和 codeproject 的几篇文章的好链接
http://aspnet.4guysfromrolla.com/articles/081705-1.aspx http://aspnet.4guysfromrolla.com/articles/103002-1.aspx http://www.codeproject.com/KB/security/SimpleEncryption.aspx
【讨论】：
由于您的问题是关于存储方法和大小的，我将解决这个问题。
存储类型可以是二进制或文本表示（base64 是最常见的）。二进制更小，但我发现使用文本更容易。如果您正在按用户进行加盐（每个密码使用不同的盐），那么将盐 + 哈希存储为单个组合字符串会更容易。
大小取决于哈希算法。 MD5的输出总是16字节，SHA1总是20字节。 SHA-256 和 SHA-512 分别是 32 和 64 字节。如果您使用文本编码，您将需要更多的存储空间，具体取决于编码方法。我倾向于使用 Base64，因为存储相对便宜。 Base64 将需要大约 33% 的大字段。
如果您对每个用户进行盐渍化，您还需要空间用于散列。将它们放在一起 64 位盐 + SHA1 哈希（160 位）base64 编码需要 40 个字符，所以我将其存储为 char(40)。
最后，如果您想正确处理，您不应该使用单个散列，而是使用像 RBKDF2 这样的密钥派生函数。 SHA1 和 MD5 哈希值非常快。即使是单线程应用程序也可以每秒散列大约 30K 到 50K 的密码，这在四核机器上每秒最多可以处理 200K 密码。 GPU 每秒可以散列 100 到 1000 倍的密码。以这样的速度，蛮力攻击成为一种可接受的入侵方法。 RBKDF2 允许您指定迭代次数以微调散列的“慢”程度。关键不是要让系统崩溃，而是要选择多次迭代，以便限制哈希吞吐量的上限（比如每秒 500 个哈希）。未来的证明方法是在密码字段中包含迭代次数（迭代 + 盐 + 哈希）。这将允许在未来增加迭代以跟上更强大的处理器的步伐。为了更灵活地使用 varchar 以允许将来可能更大/替代的哈希值。
.Net 实现是 RFC2892DeriveBytes http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
【讨论】：