security - 使用 bcrypt 为移动应用散列 5 位密码

Question

我们的应用程序使用 bcrypt 以哈希格式存储普通密码，成本(轮数)为 15。在我们的生产服务器上检查密码的有效性只需要 1 秒多一点的时间，这对于每一次 session Action 。

我们现在正在开发和保护我们的应用程序。在首次使用常用凭据(登录名和密码)登录后，我们将为用户提供设置 5 位密码的机会。

使用较低的 bcrypt 成本(即 13)来散列这些密码是否合理？

我的考虑:

• 成本越低，访问速度越快，这对我们的应用用户来说至关重要。
• 较低的成本不会带来很大的安全风险，因为单独的密码是无用的(它们是设备绑定(bind)的)。
• 与许多替代哈希机制相比，它仍然很强大。

Answer 1

Would it be reasonable to use a lower bcrypt cost (i.e. 13) to hash these passcodes?

简而言之，是的。或者完全废弃 bcrypt(见下文)。

我认为这里对 key stretching 存在一些混淆和 KDFs (即 bcrypt)，以及它们与离线和在线攻击的关系。

bcrypt 等算法可以防止有人从您的服务器中提取哈希值并继续对其进行离线暴力破解或密码猜测攻击时密码被泄露。

Bcrypt 不能防止在运行时对您的应用程序进行密码猜测攻击。在这里，您可以使用服务器端应用程序逻辑来检测针对同一帐户的暴力破解，然后限制该尝试的速率。例如，一旦在特定时间段内对同一用户名进行了一定数量的错误猜测，就故意延迟响应。

The device registers itself on the server with a string consisting of time, device id and a random string.

假设设备 ID 是一个 128 位的 UUID，您已经拥有一个 128 位的标识符，如果适当随机，它实际上是不可破解的。然而，GUIDs are designed to be unique, not random正如您在其他问题中提到的那样，任何知道此值的人都已经破解了您的身份验证。

我会废弃它并使用加密安全伪随机数生成器 (CSPRNG) 简单地生成一个随机的 128 位字符串用作“安装 ID”。由于这已经很强大，因此无需对其进行加盐或通过密码扩展算法或 key 派生函数(如 bcrypt)运行它。服务器端存储版本的 SHA-256 哈希就足够了。

5 位密码可以用 17 位表示。 13 的 bcrypt 成本将有效地赋予此密码 30 位的强度。这远低于 NIST recommendation of 80 bits .

但是，让我们考虑一下这意味着什么。 Bcrypt 用于保护服务器端哈希不被使用单词列表(或在本例中为范围从 00000 到 99999 的数字列表)猜测。如果您的 128 位安装 ID 存储在服务器上，并且攻击者设法访问您的用户表，即使他们破解了存储在 bcrypt 中的 5 位密码，他们也无法以用户身份登录，因为他们不知道SHA-256 哈希是如何生成的——它们没有安装 ID。遍历每个可能的 128 位值并查明它是否散列为存储值是完全不可行的。彩虹表太大而无法存储 2¹²⁸ 组合。

为了让事情更简单，我很想放弃 bcrypt 来获取密码，并简单地将 SHA-256(密码 + 128 位随机安装 ID) 存储在服务器上。密码可以作为“安装 ID”的盐，因此用户更改密码将生成一个完全不同的哈希值，该哈希值存储在服务器端。

请注意，以上假设设备和帐户之间存在一对一关系。如果每个设备使用多个帐户，那么您应该为每个帐户添加一个额外的盐(比如 64 位)——否则选择相同密码的两个用户将具有相同的服务器端哈希值。还有一个额外的安全风险，因为“安装 ID”现在被另一个用户知道，以及与其他用户共享客户端设备所带来的所有额外风险(例如物理安全方面或恶意软件风险)。