对密码进行哈希处理时，是否应该将哈希函数名称存储在数据库中？
关于保存用户密码的加盐哈希版本，我将哈希加盐密码以及哈希之前使用的盐保存在数据库中。
我是否还应该在数据库中保存用于散列加盐密码的算法名称（例如 SHA1 或 MD5 [我不会使用 MD5！]），这样万一有人发现我使用的算法存在漏洞，我可以为未来的用户切换使用另一种算法？
注意：我不是在谈论用于生成随机哈希的算法。
In regards to saving a salted hash version of the user's password, I save in the DB the hashed salted password and the salt used before hashing it.
Should I also save in the DB the name of the algorithm used to hash the salted password (e.g. SHA1 or MD5 [I am not going to use MD5!]) so in case of someone finding a breach in the algorithm I use, I could switch to use another algorithm for future users ?
Notice: I'm not talking about the algorithm used to generate the random hash.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，这是个好主意。它的成本非常低（每个条目几个字节），并且意味着您可以在将来更改和改进存储密码的方式。 通过在每个用户下次登录时更新其密码哈希，升级到 SHA1 或其他更安全的方法将变得微不足道。
例如，假设您几年前开始使用此方法与 MD5 - 现在， 使用诸如 PBKDF2 之类的东西来散列您的密码，而不仅仅是加盐散列。
Yes, this is a good idea. It costs you very little (a few bytes per entry), and means that you can change and improve how you store passwords in future. For instance, suppose you'd started using this method with MD5 some years ago - it would now make it a trivial matter to upgrade to SHA1 or something else more secure by updating each user's password hash when they next log in.
Note you should be using something like PBKDF2 to hash your passwords, not just a salted hash.
如果您首先使用强大的加密哈希函数，则可能没有理由切换到更强的哈希函数。
网站 keylength.com 总结了计算中信息安全的最重要建议。目前，选择的哈希函数的长度应为 160 位或更多——越多越好。
如果您正在寻找通用格式，则可以使用模块化crypt 格式，包含散列函数的标识符、使用的盐、摘要以及进一步的信息（例如成本因子），格式为：
许多人建议使用bcrypt作为密码作为其密码额外的成本参数是为了调整哈希的计算成本。
If you use a strong cryptographic hash function in the first place, there will probably be no reason to switch to a stronger hashing function.
There is the website keylength.com that has a summary of the most important recommendations for information security in computing. Currently, the chosen hash function should have a length of 160 bit or more – the more the better.
And if you’re looking for a versatile format, you can use the modular crypt format that does contain an identifier of the hash function, the used salt, the digest, and further information (e.g. cost factor) in the form:
Many suggest to use bcrypt for passwords as its additional cost parameter is to adjust the computational costs of the hashing.
这是个人喜好之一。如果发现哈希算法存在弱点，您将需要更改用户密码的存储和验证方式。有多种方法可以做到这一点，存储哈希名称是一种有效的替代方法。假设
您将需要使用以下命令自动为您的用户生成新密码新的哈希算法（并通知他们）或让他们在下次登录时更改或验证密码。存储算法的方法有助于促进第二种选择（我认为这是更好的选择）。
从技术上讲，如果数据库被渗透，存储哈希算法不会降低密码的安全性，并且当您希望更改算法时，它可以为您提供更大的灵活性。
This is one of those personal preference things. In the event that a weakness in an hashing algorithm is found, you will need to alter how user passwords are stored and verified. There are multiple ways to do this and storing the name of the hash is a valid alternative. Assuming that
you will either need to automatically generate new passwords for your users with the new hashing algorithm (and notify them) or have them change or verify their password on next login. The approach of storing the algorithm helps facilitate the second alternative (which I believe is the better option).
Technically, storing the hash algorithm will not make the passwords any less secure if the database is penetrated, and it allows you greater flexibility when you wish to change algorithms.