我的密码盐应该有多长,SHA-256 是否足够好?

发布于 2024-09-08 14:18:05 字数 247 浏览 10 评论 0原文

我正在创建一个游戏社区网站,我的目标是尽快向公众发布。目前,我正在研究密码和登录。我以前只使用过 MD5,但我读过有关密码安全的内容,并听说加盐是目前的最佳选择。

我的计划如下:每个用户都有自己独特的 12 个随机字符(#/¤& 等)盐,存储在用户表中。盐值在注册时与密码一起进行哈希处理(使用 SHA-256),并在登录时重新进行哈希处理。

您觉得这怎么样?有什么我可以改进的吗?我应该选择 SHA-512 和更长的盐,还是这样就足够了?

I'm in the process of creating a gaming community site that I'm aiming to release to the public soon. Currently, I'm working on passwords and logins. I've only used MD5 before, but I've read about password safety and heard that salting is currently the way to go.

Here's my plan: Every user has their own unique salt of 12 random characters (#/¤& etc), stored in the users table. The salt is hashed (using SHA-256) along with the password on registration, and re-hashed on login.

How does this sound to you? Anything I can improve? Should I go for SHA-512 and a longer salt, or is this enough?

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

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

发布评论

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

评论(6

三生一梦 2024-09-15 14:18:05

您建议的 12 个字节对于盐来说应该是足够的长度。这需要字典攻击来准备 296 个哈希密码数据库。有一天,这对于破解者来说可能是一个微不足道的操作,但我们距离这一目标还有很长的路要走。

NIST 推荐 SHA256,因为它对密码具有足够的哈希强度,至少目前如此。

如果您想探索更强大的密码安全方法,请研究密钥强化技术,例如 PBKDF2,或使用 Bcrypt 进行自适应哈希处理。但这些在 SQL 中没有直接支持。您必须在应用程序代码中进行哈希处理,然后将哈希摘要发布到数据库中。

对于游戏网站来说,这似乎在安全方面有些过分,但这是一个很好的做法。因为许多用户(不建议)使用与银行登录相同的密码进行游戏登录!您不想对间接导致重大损失的身份验证违规负责。

Your suggestion of 12 bytes should be an adequate length for a salt. That would require a dictionary attack to prepare 296 databases of hashed passwords. Someday this might be a trivial operation for a cracker, but we're still a ways off from that.

SHA256 is recommended by NIST as having adequate hashing strength for passwords, at least for now.

If you want to explore even stronger methods of password security, look into key-strengthening techniques like PBKDF2, or adaptive hashing with Bcrypt. But these have no direct support in SQL. You'd have to do the hashing in application code and then post the hash digest to your database.

It may seem like security overkill for a gaming site, but it's a good practice to do it. Because many users (inadvisably) use the same password for their gaming login as they do for their banking login! You don't want to be responsible for an authentication breach that leads indirectly to major losses.

泪痕残 2024-09-15 14:18:05

更新:

不要使用散列或 HMAC。使用bcryptscrypt。请参阅http://codahale.com/how-to-safely-store- a-password/

原文:

不要简单地散列。使用 HMAC。 (如果有可用的库,请避免自己进行哈希或加密,因为库受益于专家的输入。)

参考文献:

  1. http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed- hashes-use-hmac/
  2. https://www.hashes-use-hmac/ php.net/manual/en/function.hash-hmac.php

Update:

Don't use hashing or HMAC. Use bcrypt or scrypt. See http://codahale.com/how-to-safely-store-a-password/

Original:

Don't simply hash. Use HMAC. (And avoid doing your own hashing or crypto if there is a library available, since libraries benefit from expert input.)

References:

  1. http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/
  2. https://www.php.net/manual/en/function.hash-hmac.php
与风相奔跑 2024-09-15 14:18:05

这可能足以满足您的用例。

但是,可以通过以下方式进行改进:

  1. 增加盐的大小

  2. 盐不应限于字符的一小部分

  3. 迭代哈希,例如 1000 次(密钥强化)

看看 phpass

It's probably sufficient for your use case.

However, it could be improved by:

  1. Increase the size of the salt

  2. The salt should be not be limited to a small subset of characters

  3. Iterate the hashing, say 1000 times (key strengthening)

Have a look at phpass.

薄荷港 2024-09-15 14:18:05

我注意到对于如何正确进行密码哈希处理存在很多困惑,尤其是在 stackoverflow 上。我见过一些非常糟糕的建议。所以我写了一个页面来清除所有内容。它比使用简单的哈希要多一些。

更多信息和源代码:如何正确进行密码哈希

每当有人对密码哈希有疑问时,可以免费分享此链接。这是我在 stackoverflow 上的第一篇文章,如果我做得不对,很抱歉

I've noticed a lot of confusion about how to do password hashing properly, especially on stackoverflow. And I've seen some REALLY BAD recommendations. So I've written a page that should clear everything up. There's a bit more to it than using a simple hash.

More info and source code: How to do password hashing properly

Feel free to share this link whenever someone has a question about password hashing. This is my first post on stackoverflow so sorry if I'm not doing it right

熊抱啵儿 2024-09-15 14:18:05

如果您真的很担心,我会考虑使用漩涡哈希函数而不是 SHA 变体之一。 Whirlpool 已被证明是一种非常强大的哈希方法,并且没有冲突历史或任何其他弱点(至少我知道)。

您可以通过使用 hash 函数来使用 Whirlpool PHP 的。 (但请注意,hash() 需要 PHP 5.1.2 或更高版本。)

If you are really concerned, I would look at using the whirlpool hashing function instead of one of the SHA variants. Whirlpool has proven to be an incredibly strong hashing method, and has no history of collisions or any other weaknesses (that I know of, at least).

You can use whirlpool by employing the hash function of PHP. (Note, however, that hash() requires PHP 5.1.2 or greater.)

心是晴朗的。 2024-09-15 14:18:05

你目前的做法就足够了。

Your current approach is enough.

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