我应该使用哪个密码哈希函数?

发布于 2024-10-28 17:13:24 字数 377 浏览 1 评论 0原文

我正在寻找一个可以陪伴我多年的密码哈希函数。选择错误的哈希值可能是致命的,因为在用户不登录的情况下不可能升级现有的哈希值。

通常建议使用 glibc 中的 bcrypt 或 sha256-crypt。这些使用 按键拉伸, 但我不喜欢这样的事实:我以后无法延长伸展运动。 人们应该能够跟上摩尔定律。

现在,我正在考虑维基百科链接中的简单算法,使用 SHA-256 作为哈希函数。这允许我继续添加我认为合适的迭代。

然而,该算法不是标准。因此,我不太可能将密码哈希与 LDAP、htaccess 等一起使用。

有更好的选择吗?

I am looking for a password hash function that can stay with me for years. Picking the wrong one can be fatal, as it is impossible to upgrade the existing hashes without having the users log in.

It is often suggested to use bcrypt or sha256-crypt from glibc. These use
key stretching,
but I do not like the fact that I am unable to extend the stretching later on.
One should be able to keep up with Moore's law.

Right now, I am considering the simple algorithm from the Wikipedia link, with SHA-256 for the hash function. That one allows me to just keep adding iterations as I see fit.

However, that algorithm is not a standard. It is therefore unlikely that I will ever be able to use the password hash with LDAP, htaccess, and so on.

Is there a better option available?

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

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

发布评论

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

评论(2

瘫痪情歌 2024-11-04 17:13:24

我可能是从另一个角度来看这个问题,但如果你说你可能有长时间不登录的用户,那么这就带来了很大的风险。您允许用户使用相同密码的时间越长,攻击者以某种方式获取您的密码哈希文件的暴力破解风险就越大。不要依赖安全性来防止这种情况的发生...

哈希函数不会那么快过时,所以我想你应该每年检查一次,因为希望你能让你的用户更频繁地更改密码。

显然,这一切都取决于您的具体要求,但请考虑一下。

一般来说,bcrypt 或 sha256 可以很好地满足要求。

更新:您可以考虑将此查询弹出到 security.stackexchange.com,因为这是一个安全管理问题。

I may be coming at this from another angle, but if you are saying that you may have users who will not log in for long periods of time then that presents a big risk. The longer you allow a user to stick with the same password, the greater the risk of bruteforce from an attacker who manages to grab your password hash file somehow. Don't rely on security preventing that ever happening...

Hash functions don't go out of date that rapidly, so I would imagine you should be fine reviewing this annually, as hopefully you will have your users change passwords more often than that.

It all depends on your exact requirements, obviously, but have a think about it.

In general bcrypt or sha256 can suit the requirement nicely.

Update: You could think about popping this query across to security.stackexchange.com, as it is a security management question.

圈圈圆圆圈圈 2024-11-04 17:13:24

您应该使用 SHA1 进行密码散列。然而,除了算法之外,您还应该考虑在密码中添加盐。理想情况下,应该为每个密码创建一个随机盐并与密码一起存储。

这是为了打败彩虹表。

对此进行了精彩的讨论:密码哈希的非随机盐

You should use SHA1 for password hashing. However, more than algorithm, you should also consider adding salt to passwords. Ideally a random salt should be created for each password and stored along with password.

This is to defeat rainbow tables.

Great discussion on this : Non-random salt for password hashes

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