更改现有数据库上的哈希函数
我正在阅读一些有关密码哈希的内容。我见过 SHA-256 > MD5。 这让我思考应用程序如何处理从一种哈希函数到另一种哈希函数的变化。如果有人实现一个使用 MD5 对其密码进行哈希处理的应用程序，会发生什么情况。然后他们决定 SHA-256 是最佳选择。当然，存储在数据库中的密码哈希值是 MD5 格式的。
将数据库中的数据从一种哈希函数迁移到另一种哈希函数的过程是什么？
I'm doing a bit of reading on hashing for passwords. I've seen that SHA-256 > MD5.
This got me thinking about how an app may deal with changing from one hashing function to another. What happens if someone implements an app that hashes their passwords using MD5. They then decide that SHA-256 is the way to go. But of course the password hashes stored in the database are in MD5.
What is the process for migrating the data in the database from one hashing function to another?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不可能对密码进行“散列”处理（至少不能以通用、高效和可靠的方式进行处理 - 您可以猜测一些密码，这就是攻击者所做的，而您想要从 MD5 迁移正是因为攻击者可能会取得一些成功）。因此，迁移将随着时间的推移而分散：一些密码将使用 MD5 进行哈希处理，其他密码将使用 SHA-256 进行哈希处理。当要验证密码时：
因此，密码是动态迁移的；要彻底摆脱MD5，您必须等待很长时间和/或销毁长时间未访问的帐户。您需要能够区分 MD5 哈希值和 SHA-256 哈希值，这很容易，因为它们具有不同的大小（MD5 为 16 字节，SHA-256 为 32 字节）。您还可以添加一面旗帜或任何其他类似的花招。
请注意，从安全角度来看，使用哈希函数的原始单一应用程序对密码进行哈希处理是一种非常糟糕的方法，并且用 SHA-256 替换 MD5 不会真正改善情况。您对密码进行哈希处理，以便获得数据库读取访问权限的攻击者自己不会获知密码。为了真正防止攻击者猜测密码，您还需要“盐”（每个密码的随机数据，与散列密码一起存储）和一个适当慢的散列函数（即数千个，可能数百万个嵌套哈希函数调用）。有关详细信息，请参阅此答案。简短的回答：既然您正在考虑迁移，那就明智地迁移到 bcrypt，而不是SHA-256（参见security.stackexchange 上的答案 ）。
It is not possible to "unhash" passwords (at least not in a general, efficient and reliable way -- you can guess some passwords, that's what attackers do, and you want to migrate from MD5 precisely because attackers may have some success at it). So the migration will be spread over time: some passwords will be hashed with MD5, other with SHA-256. When a password is to be verified:
Thus, passwords are migrated dynamically; to get totally rid of MD5, you have to wait a long time and/or destroy accounts which have not been accessed for a long time. You need to be able to distinguish a MD5 hash from a SHA-256 hash, which is easy since they have distinct sizes (16 bytes for MD5, 32 bytes for SHA-256). YOu could also add a flag or any other similar gimmick.
Please note that hashing passwords with a raw single application of a hash function is a pretty lousy way of doing it, security-wise, and replacing MD5 with SHA-256 will not really improve things. You hash passwords so that an attacker who gains read access to the database will not learn the passwords themselves. To really prevent the attacker from guessing the passwords, you also need "salts" (per-password random data, stored alongside the hashed password) and a suitably slow hash function (i.e. thousands, possibly millions, of nested hash function invocations). See this answer for details. The short answer: since you are envisioning migration, do the smart thing and migrate to bcrypt, not SHA-256 (see that answer on security.stackexchange).