使用 ASP.NET MVC 3 对密码进行哈希处理
我现在正在尝试找出对 ASP.NET MVC 3 应用程序的密码进行哈希处理的最佳方法。据我所知，最好使用给定的密码和随机盐，然后将散列密码和盐存储在一起。我的问题是这不会让随机盐变得毫无意义吗？我的意思是对密码进行哈希处理的原因是因为如果有人进入您的数据库，他们没有纯密码，并且盐使得反转哈希值以获取密码变得更加困难，但是如果我将哈希值存储为密码，盐的意义是什么（我对散列的知识非常有限，所以我的想法可能完全错误）。
我的第二个问题是哪种哈希方法是最好使用的？我读到MD5（这是我一直使用的）很容易破解。我听说 bcrypt/sha512 相当不错。应该使用哪一个？我知道 C# 默认带有 sha512 哈希。据我所知，bcrypt 未包含在 .NET 库中，是否有适用于 C# 和 bcrypt 的好的库？
I am right now in the process of trying to figure out the best way of hashing the password for my ASP.NET MVC 3 application. From what I hear, it is good to use the given password and a random salt and then store the hashed password and salt together. My question is won't that make the random salt pointless? I mean the reason to hash a password is because if someone get into your database, they don't have the plain passwords and the salt make it much much harder to reverse the hash to get the password but but if I store the hash with the password, what is the point of the salt (my knowledge on hashing is every limited so I could be completely off base with my thinking).
My second question is what hashing method is the best one to use? I read that MD5 (which is what I have always used) is very simple to crack. I hear the bcrypt/sha512 are pretty good. Which one should use? I know that C# by default comes with the sha512 hashing. From what I can see, bcrypt is not included in the .NET library, are there any good libraries for C# and bcrypt?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
无需将盐存储在不同的位置，您应该始终假设攻击者知道盐，并且其目的不是作为额外的密码！
在.NET中，这个API将完成您需要的一切，它将在每次AES加密传递之前通过字节交换创建大的加密随机盐以及HMACSHA512散列和密钥拉伸:)
http://sourceforge.net/projects/pwdtknet/
there is no need to store the salt in a different location, you should always assume salt in known by an attacker anyway and its purpose is not to be an extra password!!!!
In .NET this API will do everything you need, it will create big crypto random salt as well as HMACSHA512 hashing and key stretching via byte swapping before each AES encryption pass :)
http://sourceforge.net/projects/pwdtknet/
加盐会增加对彩虹/字典攻击的抵抗力。今年发生的一些安全漏洞是因为 Web 应用程序的数据库包含没有加盐的密码，并且是使用 md5 完成的。因此，简单的彩虹攻击可以在几秒钟内为一些使用糟糕密码的用户生成密码。
为了使用 MVC 3 提供用户身份验证，您确实应该使用该框架来完成此类事情。如果您做得不对，那么使用您自己的自定义身份验证提供程序可能会导致问题。
看看
http://msdn.microsoft.com/en -us/library/ff398049%28v=VS.98%29.aspx 和 http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx。如果您使用.NET 会员系统，则不需要执行任何低级数据库或密码管理。您只需将 [Authorize] 标签放在需要验证的控制器操作周围即可完成。
Salting will increase the resistance against a rainbow/dictionary attack. A few security exploits that have occurred this year were because the web application's database contained passwords without a salt and they were done with md5. So a simple rainbow attack produced the password within seconds for a few users that used terrible passwords.
For providing user authentication with MVC 3, you should really use the framework for this sort of thing. Coming up with your own custom authentication provider could cause problems if you don't do it right.
Take a look at
http://msdn.microsoft.com/en-us/library/ff398049%28v=VS.98%29.aspx and http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx. If you use the .NET membership system, you don't need to do any low level database or password management. You just put the [Authorize] tags around the controller actions that need to be auth'd and your done.
这是 bcrypt 的一个很好的 C# 实现：
http://bcrypt.codeplex.com/
Here's a nice C# implementation of bcrypt:
http://bcrypt.codeplex.com/
SHA512 是 .net 中散列的一个不错的选择，如果您将盐与密码一起存储，那么它有点毫无意义（但“解密”仍然需要更长的时间），但是您可以将盐存储在其他地方，因此数据库还不够：
更新：
正如迈克已经说过的，我对上面“毫无意义”的说法是错误的。即使盐是已知的，它也会使 Rainbow Table 攻击变得无用（或者更不可能），因此，即使将盐存储在哈希值旁边，您也应该始终使用盐（例如，Linux确实将用户密码存储在 影子文件，格式为“$id$salt$hashed”）！
SHA512 is a good choice for hashing in .net and if you store the salt with the password it is a little bit pointless (but the "decrypting" still would need a longer time), but you could store the salt somewhere else, so the DB isn't enought:
UPDATE:
As Mike already stated I am wrong with the "pointless" statement above. Even when the salt is known it will render Rainbow Table Attacks useless (or a lot more unlikely), so you should always use a salt even when storing the salt right next to the hash (linux for example does store the user passwords in the shadow file in a form of "$id$salt$hashed")!
我一直使用以下方法来存储密码
是否可以将此类哈希恢复为原始密码从来都不是问题。
I have allways used the following approach to store passwords
It's has never been a question if it is possible to restore such hash to original password.
如果他们侵入您的安全数据库以窃取人们的散列密码，那么他们当时不太可能真正需要该密码。他们很可能已经可以访问数据库中的所有数据。如果简单的数据没有价值，MD5 哈希值对于一般网站来说可能就足够了。对于更有价值的数据，其他更困难的散列方法也可以。
If they hacked into your security database to steal people's hashed password, then it is unlikely that they would really need the password at that point. They already have access to all the data in the database most likely. An MD5 hash is probably fine for the average website if it is something simple with data that is not valuable. Other more difficult hashing methods would be fine for data that is more likely to be valuable.