我应该更喜欢具有较长输出的哈希算法来存储密码吗?

发布于 2024-12-04 14:08:54 字数 294 浏览 1 评论 0原文

我正在构建一个安全性比较重要的网站(话又说回来,什么时候安全性不重要?),并且我一直在寻找存储密码的最佳方法。我知道 MD5 和 SHA-1 一样存在冲突问题,因此我正在考虑通过 SHA-256 或 SHA-512 存储我的密码。

存储较长的哈希变体比存储较小的哈希变体更明智吗? (即 512 与 256)与 SHA-256 编码的密码相比,破解 SHA-512 编码的密码是否需要更多的时间?

另外,我读过有关使用“盐”作为密码的内容。这是什么以及它是如何工作的?我是否只需将盐值存储在另一个数据库字段中?如何将其用作哈希值计算的一部分?

I'm building a site where security is somewhat important (then again, when is it not important?) and I was looking for the best way to store my passwords. I know that MD5 has issues with collisions as well as SHA-1, so I was looking into storing my passwords via either SHA-256 or SHA-512.

Is it wiser to store a longer hash variant as opposed to a smaller one? (ie 512 vs 256) Does it take significantly more time to crack a SHA-512 encoded password versus a SHA-256 encoded password?

Also, I've read about using "salts" for the passwords. What is this and how does it work? Do I simply store the salt value in another database field? How do I use that as a part of the hash value calculation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

江湖彼岸 2024-12-11 14:08:54

对于密码存储,您需要的不仅仅是哈希函数;您需要:

  • 一个极其慢的哈希函数(以便暴力攻击更加困难)
  • 和一个盐:一个公开的值,沿着哈希存储,每个哈希密码都是不同的,并进入密码哈希过程。盐可以防止攻击者有效地攻击多个密码(例如使用预先计算的哈希表)。

所以你需要bcrypt

对于哈希输出大小:如果该大小为 n 位,则 n 应使得攻击者无法实际计算哈希函数 2n 次; 80 位就足够了。因此 128 位的输出已经有些过大了。您仍然不想使用 MD5,因为它太快了(尽管 100000 次 MD5 嵌套调用可能足够慢),并且因为在 MD5 中发现了一些结构性弱点,这些弱点不会直接影响其散列密码的安全性,但公共关系仍然很糟糕。无论如何,你应该使用 bcrypt,而不是自制的结构。

For password storage, you need more than a mere hash function; you need:

  • an extremely slow hash function (so that brute force attacks are more difficult)
  • and a salt: a publicly known value, stored along the hash, distinct for each hash password, and entering in the password hashing process. The salt prevents an attacker from efficiently attacking several passwords (e.g. using precomputed hash tables).

So you need bcrypt.

For the point of the hash output size: if that size is n bits, then n shall be such that an attacker cannot realistically compute the hash function 2n times; 80 bits are quite enough for that. An output of 128 bits is thus already overkill. You still would not want to use MD5, because it is way too fast (100000 nested invocations of MD5 might be slow enough, though) and because some structural weaknesses have been found in MD5, which do not directly impact its security for hashing passwords, but are bad public relations nonetheless. Anyway, you should use bcrypt, not a homemade structure.

山有枢 2024-12-11 14:08:54

这里的一些答案给了你可疑的建议。我建议您前往 IT Security Stack Exchange 并搜索“密码哈希”。您会发现很多建议,其中大部分已经过安全堆栈交换人员的仔细审查。或者,你可以听@Thomas Pornin,他知道他在说什么。

Some of the answers here are giving you dubious advice. I recommend you to head over to the IT Security Stack Exchange and search on "password hashing". You will find lots of advice, and much of it has been carefully vetted by folks on the security stack exchange. Or, you could just listen to @Thomas Pornin, who knows what he is talking about.

和影子一齐双人舞 2024-12-11 14:08:54

碰撞与您的场景无关,因此 MD5 的弱点与您的场景无关。然而,最重要的是使用需要很长时间计算的哈希。阅读 http://codahale.com/how-to-safely-store-a -password/http://www.jasypt.org/howtoencryptuserpasswords.html (即使您不使用 Java,这些技术仍然有效)。

无论如何,我都会远离 MD5,因为还有其他表现同样好的哈希值。

Collisions are not relevant in your scenario, so MD5's weaknesses are not relevant. However, the most important thing is to use a hash that takes a long time to compute. Read http://codahale.com/how-to-safely-store-a-password/ and http://www.jasypt.org/howtoencryptuserpasswords.html (even if you're not using Java the techniques are still valid).

I would stay away from MD5 in any case, since there are other hashes that perform just as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文