我们继承了一个有 300 万用户登录的系统，在一个 CSV 中分成 500k 块，密码未散列。
客户反对建议，决定他想保留相同的密码，但只是为新系统散列它们，而不是强迫用户设置新密码，所以请不要回复说“不要这样做”。
我们目前正在使用 PHP 来处理文件以规范化数据和 bcrypt 现有的字符串。
然而在 200 条记录上运行测试，当我们将 bcrypt 添加到循环中时，该过程需要大约 7 秒。
随着时间的推移，这显然会增加很多。
有人对我们如何以更快的速度将字符串转换为 bcrypt 有其他建议吗？我在想也许有一个命令行工具，我们可以将 CSV 传递给它，它“知道第 4 列”是密码，并将其散列，然后保存回文件或其他东西。
欢迎在这一点上提出任何建议。
值得一提的是，我们需要在发布当天重复此过程，以便将停机时间降至最低？
非常感谢
更新
对于那些感兴趣的人，在 2012 年的 MBP 上，2.6Ghz i7 和 8GB ram 需要 9 个小时才能完成第一轮，运行 6 个脚本实例，每个实例处理 50 万个用户。
好吧，事实上 bcrypt 很慢是关键——它应该很慢以使其更能抵抗蛮力破解。
我只能想到几个选项：
划分任务并使用更多线程/处理器/计算机。
使用较低的“复杂性”因素。这将使散列更快，但会在一定程度上降低散列的安全性，因此不是一个很好的选择。
至于在发布当天使流程运行得更快以避免停机，我的建议如下：
现在 Bcrypt 所有 250 万个帐户，并将 bcrypt 散列与用户帐户一起存储在您的新系统中。
此外，计算密码的简单 SHA 哈希值，并将其与关联的用户 ID 离线存储在文件中。
在上线当天，再次从旧系统中获取所有帐户。对于在步骤 1 之后创建的新帐户，使用 Bcrypt 哈希在新系统中创建帐户。对于其他帐户，请检查 SHA 哈希（快速计算）是否与您在步骤 2 中创建的文件中的 SHA 哈希匹配。如果不是，请重新 bcrypt 密码并更新新系统。如果它们匹配，则无需再次 bcrypt。