在 C# 中存储使用 MD5CryptoServiceProvider 散列的密码是否安全？
我们将哈希密码存储在数据库表中。
我们使用 MD5CryptoServiceProvider 在每个密码前添加一个随机盐值和哈希值。
这安全吗？我听说 MD5 被“破坏”了。
如果没有，您能否推荐使用替代的哈希方法（特定的 .NET 框架类）？
We are storing hashed passwords in a database table.
We prepend each password with a random salt value and hash using MD5CryptoServiceProvider.
Is this safe? I have heard MD5 was "broken".
If not, can you recommend an alternate hash method to use (specific .NET framework class)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
哈希函数的安全性主要来自于其输出（消息摘要）的长度：摘要越长，抗碰撞能力就越大。生日悖论告诉我们，平均而言，您会期望从摘要大小的平方根的工作函数中找到冲突：换句话说，给定 128 位摘要，攻击者预计会在 2^ 之后命中 paydirt 64 次试验。
MD5 多年来一直受到密码学界的不满，因为它只有 128 位摘要，而且还有一些有趣的密码分析结果可能会有效降低其强度。 SHA1（160 位摘要）一直是首选的替代方案，但即便如此，对于动机良好的对手来说，它的长度似乎还不够长，而且研究界也有一些有趣的结果。 SHA-2 系列（输出大小从 224 到 512 位）是当前广泛使用的首选哈希函数。 NIST 组织了一项积极的研究竞赛来寻找 SHA-2 的继任者，但我们要到 2012 年左右才会有新的标准。
现在，在存储密码的特定情况下，我注意到您正在使用盐。这是强烈推荐的做法；如果没有盐，您将很容易受到彩虹表攻击。我相信这让你只需要考虑暴力攻击；这就是 keylength.com 的用武之地。它汇集了整个加密社区对密钥和摘要大小的建议，考虑到当前的计算能力并考虑摩尔定律，给出了各种算法的预期安全时间表。考虑您正在保护哪种资产以及您需要密码来保持安全多长时间（例如，您是否有强制的密码更改策略？），这应该几乎可以回答您所需的摘要大小的问题。
当然，如果您的用户使用易于猜测的密码，那么世界上最好的密码存储也无济于事。您是否为用户提供强密码提示？您是否考虑过密码强度计或类似工具？
The security of a hash function mainly comes from the length of its output (message digest): a longer digest gives greater collision resistance. The birthday paradox tells us that on average you'd expect to find a collision from a work function of the square root of the digest size: in other words, given a 128-bit digest, an attacker would expect to hit paydirt after 2^64 trials.
MD5 has been frowned upon by the cryptographic community for some years now because it only has a 128-bit digest, and there are also some interesting cryptanalytic results which might effectively reduce its strength. SHA1 (160 bit digest) had been the preferred alternative, but even then it is starting to look like it was not long enough for a well-motivated adversary and there are also some interesting results in the research community. The SHA-2 family (output sizes from 224 to 512 bits) are the current preferred hash functions in widespread use. There is an active research competition organised by NIST to find a successor for SHA-2, but we won't have a new standard until 2012 or so.
Now, in the specific case of storing passwords, I note you are using a salt. This is the strongly recommended practice; without a salt you would be vulnerable to a rainbow table attack. I believe that this leaves you with only the brute force attack to consider; this is where keylength.com comes in. It brings together recommendations for key and digest sizes from across the cryptographic community and gives expected security timescales for various algorithms, considering current computing power and taking Moore's Law into account. Consider what sort of assets you are protecting and how long you need to a password to remain secure for (do you have an enforced password change policy, for example?) and that should pretty much answer the question of the digest size you need.
Of course, the best password storage in the world won't help you if your users use easy-to-guess passwords. Do you provide your users with tips for strong passwords? Have you considered a password strength meter or similar?
我认为 SHA256、SHA512 目前更安全:)
请参阅 wiki
I think SHA256, SHA512 are more safe at this moment :)
See wiki
不，您不应该使用 MD5。但您也不应该使用单轮任何通用哈希函数，无论它的加密安全性如何！不是 MD5、不是 SHA-1、不是 SHA-2、不是 SHA-3。
为什么？因为通用哈希函数被设计为快速。而快速正是您在密码哈希中不想要的。快速意味着当坏人获得您的数据库时，他们可以在合理的时间内对其进行普通的旧字典攻击。
你需要的是慢。最简单的减慢速度的方法是迭代快速哈希函数数千次 - 这就是用于在类 UNIX 系统上存储密码的基于 MD5 和 SHA-1 的密码方案所做的事情（它不仅仅是一轮 MD5 或 SHA-1） ）。另一种方法是使用设计得很慢的加密原语 - 这就是“bcrypt”密码方案的作用。
这篇 Matasano 文章 关于安全密码方案您需要了解的内容，对这个主题有一些很好的读物。
No, you shouldn't be using MD5. But you shouldn't be using a single round of any general purpose hash function, no matter how cryptographically secure it is, either! Not MD5, not SHA-1, not SHA-2, not SHA-3.
Why? Because general purpose hash functions are designed to be fast. And fast is exactly what you don't want in a password hash. Fast means that when the bad guys get your database, they can run a plain old dictionary attack against it in a reasonable amount of time.
What you need is slow. The simplest way to be slow is to iterate the fast hash function thousands of times - that's what the MD5 and SHA-1 based password scheme used to store passwords on UNIX-like systems do (it's not just one round of MD5 or SHA-1). Another way is to use a cryptographic primitive that is designed to be slow - that's what the "bcrypt" password scheme does.
This Matasano article, What You Need To Know About Secure Password Schemes, has some good reading on exactly this subject.
使用盐 MD5 比不使用盐更安全，但最好使用 SHA 哈希值之一，例如 SHA256Managed。
With a salt MD5 is much more secure than without, but you're better off using one of the SHA hashes such as SHA256Managed.
存储散列密码会更好，因为它可以隐藏密码，防止 DBA 的窥探。
另外，是的，MD5 已被破坏，但至今仍在使用。如果您担心 MD5，请使用 SHA-1（MSDN 链接 此处）。它是一种类似于 MD5 的哈希算法，但更强大。您最多可以使用 512 位的 SHA-1 哈希值。
这是在 VB.NET 上完成的示例 (http://www.obviex.com/samples/hash .aspx）。
美国国土安全部阐述了为什么人们应该放弃 MD5 (http:// www.kb.cert.org/vuls/id/836068）。总结，它是“密码破解的”
Storing hashed password is better since it hides the password from prying eyes of DBA's.
Also, yes, MD5 was broken, but is still used to this day. If you are concerned about MD5, rather use SHA-1 (MSDN link here). It's a hashing algorithm just like MD5 but stronger. You can have SHA-1 hashing of up to 512 bits.
Here's an example done on VB.NET (http://www.obviex.com/samples/hash.aspx).
Here's the US Department of Homeland Security stating why people should move away from MD5 (http://www.kb.cert.org/vuls/id/836068). Summary, it's "cryptograpically broken"