我的密码盐应该多长时间，SHA-256 是否足够好?
我正在创建一个游戏社区网站，我打算尽快向公众发布.目前，我正在处理密码和登录信息.我之前只使用过 MD5，但我已经阅读了有关密码安全的文章，并听说目前可以使用 salting.
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.
这是我的计划:每个用户都有自己独特的 12 个随机字符(#/¤& 等)，存储在 users 表中.盐在注册时与密码一起散列(使用 SHA-256)，并在登录时重新散列.
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.
这听起来如何?我有什么可以改进的吗?我应该选择 SHA-512 和更长的盐，还是这样就足够了?
How does this sound to you? Anything I can improve? Should I go for SHA-512 and a longer salt, or is this enough?
推荐答案
您建议的 12 个字节应该是盐的足够长度.这需要字典攻击来准备 296 个散列密码数据库.总有一天，这对破解者来说可能是一项微不足道的操作，但我们离实现这一目标还有很长的路要走.
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.
NIST 推荐 SHA256，因为它具有足够的密码散列强度，至少目前是这样.
SHA256 is recommended by NIST as having adequate hashing strength for passwords, at least for now.
如果您想探索更强大的密码安全方法，请研究密钥强化技术，例如 PBKDF2，或使用 Bcrypt 进行自适应散列.但是这些在 SQL 中没有直接支持.您必须在应用程序代码中进行散列，然后将散列摘要发布到您的数据库中.
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.
相关文章