我一开始能用SHA散列密码，而不是用bcrypt对它们进行散列，以将请求与慢密码函数分离开来吗？

Question

我使用bcrypt对一些web服务请求哈希多个密码。问题是，由于bcrypt，这些web服务请求可能需要几分钟才能完成。不太友好的用户。

我的问题是:我可以使用SHA散列这些密码并将它们保存到数据库中，然后让一个解耦的排队工作人员来使用bcrypt正确地散出这些密码吗？

这样，这些密码最终将使用bcrypt进行散列，但用户在此过程中不会有痛苦的体验。

目前，我正在使用.NET库BCrypt.Net。

Answer 1

Bcrypt被运行了很多次，目的是让它慢下来。也许您需要调整运行的bcrypt的数量？这个回答有一些关于它的信息。

虽然您的建议可能有效，但我不能说实现标准密码处理的变体是个好主意。虽然我有一些特定的关注点，比如SHA哈希在DB中停留的时间太长，以及加密队列的安全性，但我通常不认为有必要改变标准。如果时间太长，请减少用于执行的子弹数量。如果速度慢得令人费解，那就找出原因。不要仅仅决定你可以比几十年的安全最佳实践做得更好。结果不太可能好。

也许您想发布另一个问题(可能在StackOverflow上)，询问有关查找性能问题的帮助。这似乎是个更好的主意。

抱歉我不能同意你的提议..。

Answer 2

所描述的设计将完全破坏bcrypt的安全性。

您的设计可以通过简单地消除流的bcrypt部分来简化，并且只依赖于SHA哈希。这种简化不会显着地改变设计的安全性，它仍然像简单地应用SHA哈希一样不安全。

但是，使用带有salt的SHA哈希就足以保护好的密码。只有弱密码才能受益于使用更强的密码散列。

你还没有完全描述你想要解决的问题，所以我们不能提供任何关于如何进行的坚实的建议。然而，我想到了对你问题的两种解释，每一种解释都能得到解答。

您是否试图加快大量创建用户的速度？

如果您试图加快新用户的批量创建，并被密码散列算法所减慢，那么我可以提出两种方法来改进这个非常具体的用例。

1. 使用强密码和普通密码散列。如果您最初为用户生成的密码很强，那么您就不需要bcrypt的完全安全性。具有128位熵的初始密码通过密码哈希，它执行SHA-2的单个盐渍迭代是足够安全的。一旦用户将初始密码更改为其他密码，就可以切换到不同的密码散列算法。甚至可以使用密码散列的标准格式来实现这一点，比如crypt函数曾经使用过的格式，在这种格式中，格式以使用过的散列规范开始。
2. 使用密码散列，它支持快速的初始散列，但在验证密码方面要慢一些。这可以通过应用SHA-2散列来连接salt、密码和一个短的随机位串来实现。随机位串无论如何都不会被存储，因此必须强制执行才能验证密码。这种强制操作取代了密码散列中通常使用的迭代。

您想要减少服务器上的CPU负载吗？

有一些密码散列算法，可以安全地将计算中CPU密集的部分卸载到客户端，而不影响安全性。这甚至可以通过不允许服务器查看实际密码来提高安全性。这种方法的缺点是，它需要客户端支持。客户端不能再为了登录而只提交用户名和密码。

使用哪个散列？

在任何新系统中，不要使用任何比SHA-2更弱的东西。任何使用SHA-1进行安全相关使用的遗留系统都应该被逐步淘汰或升级。任何为与安全相关的目的使用MD5的遗留系统都应该在十年前被淘汰。

SHA-2家族有六种不同的变体.不要用较短的产出，因为你认为它会更快。实际上，压缩函数只有两个变体。其中一个具有256位内部状态，并为32位CPU进行优化。另一种是512位内部状态，并为64位CPU进行优化。如果您的CPU是64位，那么SHA-512既是最快的，也可能是最安全的。

对于密码哈希，您不应该没有盐分散列。我认为这是唯一一个完全客观的建议，可以给出如何散列密码。还有很多其他的建议需要提供，但其他的将取决于威胁的情况。

Answer 3

这里的风险是，如果攻击者设法从数据库中提取SHA的密码，那么他们可以以相对较快的速度运行密码猜测攻击。您至少应该保存这些密码，但是这样就会增加复杂性，这通常与安全性不一致。一个好的安全系统应该尽可能简单才能做到这一点。

我不认为bcrypt(sha-2(password))会减少任何有意义的安全。是的，您可以将搜索空间从576位减少到256位(使用SHA-256)，但是您只需要128位熵，就可以使用当今的技术(以及可预见的未来)拥有“不可破解”的密码。所以这是一个没有意义的问题。

不要忘记，为了验证登录密码，您将不得不在每次比较时都要使用SHA-2 it (fast)和bcrypt it (slow)。因此，您的登录系统将是缓慢的，尽管这里您正在执行bcrypt而不是n * bcrypt，我认为这是批处理过程的问题所在。

我认为解决这一问题的方法是系统架构问题，而不是安全问题。调优您的bcrypt成本，这样一个有效的用户登录大约需要1秒。然后重新设计您的批处理过程，使其是异步的，并在后台对密码进行加密。有一个通知事件来返回此进程是否成功，如果没有，则返回哪些用户ID失败。这将改善您的用户体验，使您的系统不那么安全。内存比DB安全得多。