是的，用 bcrypt 再次散列是个好主意。但是请注意，它不会给您的登录代码带来更多的熵，只会增加破解的时间。因此，如果一开始的熵真的很低，您可能需要一个非常高的成本因素才能使其无法破解。

在旁注中，通常最好只使用一个好的散列函数进行散列，而不是使用许多散列函数，正如对这个问题的回答中所解释的那样。但是您没有该选项，因此那里的论点对您的情况并不真正有效。

至于使用辣椒，我建议只加密哈希值。它提供了相同的保护，但提供了更大的灵活性。但它不能替代盐渍。

这和这对你来说可能是有趣的阅读。此外，Roshan Bhumbra有一个有趣的建议，即在第一次登录后仅使用一个函数进行重新散列。

传输中的加密

在您当前的系统中，事实上的密码似乎是“此登录代码的 SHA-1 哈希”，因为拥有匹配的哈希足以生成有效文件，但尚不清楚它是否允许攻击者直接利用某些东西。但是，在这方面，它的安全性不亚于简单地发送明文密码-只要您通过安全和加密的通道（即正确的 https / sftp / 等）“获取文件”即可。

存储加密

该系统的一个风险是，如果攻击者可以获得该文件的副本，那么他们可以获得用户的完整密码。如果您需要存储这些哈希值，那么您是对的，使用 bcrypt 对它们进行哈希存储是合理的，主要问题是您需要确保立即删除收到的 SHA-1 哈希值并且没有它（例如临时文件、备份、缓存等）保留在存储中。

我看到另一个似乎没有被提及的选项，尽管如果生成哈希的系统可以使用 Bcrypt，这会更好。

您只需要在用户登录时更新哈希。虽然这意味着您将同时使用两种不同的哈希算法，但它解决了@Anders 提到的关于在一个值上使用两种算法的“问题”。

您可以在散列旁边存储一个值来告诉应用程序它是哪种类型，如果是 SHA-1 散列，那么您可以散列他们刚刚输入的密码（如果它是正确的）并存储它。

如果原始哈希没有加盐，那么您可以简单地将任何加盐哈希算法应用于您收到的原始未加盐哈希。

然而，重要的是在您的数据库中清楚地标记这些散列正在使用组合散列算法。以后您的数据库中将使用不同的哈希算法保护不同的用户，这并非完全不可能。那时，重要的是您知道为数据库中的每个用户使用的正确函数。

下次用户登录时，可以升级数据库中存储的哈希值。虽然这可能并不重要，因为 bcrypt 仅比 SHA1 和 bcrypt 稍微安全一些。

如果原始哈希被加盐，它会变得更加棘手。在这种情况下，您仍然可以应用两层散列，但在这种情况下，存储所有盐和仅存储最后一个散列值非常重要。