使用带盐的哈希将密码存储在数据库中；不知道在哪里/如何储存盐
我有一个 ASP.NET (MVC 3) 网站，用户可以登录该网站来执行某些操作。我需要将他们的密码存储在后端 SQL Server 2008 数据库中。我将使用表单身份验证（不是 Windows 身份验证）。我只是想知道在数据库中存储密码的最佳方式是什么。阅读一些链接，例如 this，我倾向于使用带盐的哈希，但我不清楚关于如何存储盐值？盐值应该加密吗？在采用这种方法之前，有人还有其他想法、最佳实践、潜在问题或关键考虑因素吗？
I have a ASP.NET (MVC 3) web site where user will be able to login to perform certain actions. I need to store their password in backend SQL Server 2008 database. I will be using form authentication ( not windows authentication). I am just wondering what is the best way of storing the password in database. Reading some links like this, I am inclining towards using Hash with Salt but I am unclear on how to store the salt value? Should salt value be encrypted? Any one have other ideas, best practices, potential problem or key considerations before concluding with this approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，盐作为哈希的一部分存储，有时作为前两个字节。如有必要，可以将其存储为单独的字段，尤其是当盐较长时。盐不需要加密。您只需将盐+哈希存储在相当安全的（仅限管理员访问）位置。
永远不要存储实际密码。你只需要盐和哈希。当用户提供密码时，您可以使用他们声称的用户存储的盐对其进行加密，如果结果与存储的哈希值匹配，则密码是正确的。
关于该主题的一篇好文章：http://www.obviex.com/samples/hash.aspx< /a>
Typically the salt is stored as part of the hash, sometimes as the first two bytes. It can be stored as a separate field if necessary, especially when the salt is longer. The salt does not need to be encrypted. You just store the salt+hash in a reasonably-secure (admin access only) location.
Don't ever store the actual password. You only need the salt and hash. When the user gives a password, you encrypt it using the stored salt for the user they claim to be, and if the result matches the stored hash, the password is correct.
A good article on the subject: http://www.obviex.com/samples/hash.aspx
典型的方法是将盐和哈希存储在一起，并用一些特殊字符分隔。该值由身份验证机制创建，并且可以传递给身份验证机制进行验证，这样应用程序本身就不必知道该值同时包含 salt 和 hash。
盐未加密存储。
A typical approach is to store the salt and the hash together, separated by some special character. This value is created by the authentication mechanism and can be passed to the authentication mechanism to verify, so that the application itself does not have to know that the value contains both a salt and a hash.
The salt is not stored encrypted.