security - bcrypt 对大型网站可行吗？

Question

我已经参与 bcrypt 潮流一段时间了，但我无法回答一个简单的烦人的问题。

想象一下，我在美国有一个相当成功的网站……大约有 100,000 个活跃用户，每个用户的事件模式在一个典型的美国工作日(包括时区时为 12 小时)平均需要 2 到 3 次身份验证尝试。即每天 250,000 个身份验证请求，或每秒约 5.8 个身份验证。

关于 bcrypt 的一项巧妙之处在于您可以对其进行调整，以便随着时间的推移它像硬件一样扩展，以保持领先于破解者。一个常见的调整是让它每次哈希创建花费超过 1/10 秒......假设我得到它每个哈希值 0.173 秒。我选择这个数字是因为碰巧每个散列 0.173 秒相当于每秒 5.8 个散列。换句话说，我假设的 Web 服务器实际上把所有时间都花在了对用户进行身份验证之外什么都不做。不要介意实际做任何有用的工作。

为了解决这个问题，我要么将 bcrypt 调低(不是一个好主意)，要么得到一个专门的服务器来进行身份验证，别无他法。现在想象一下，该站点不断增长并增加了 100,000 名用户。突然间我需要两台服务器:同样，除了身份验证什么都不做。甚至不要开始考虑负载峰值，因为您一整天都有轻松和忙碌的时期。

正如我现在所看到的，这是最好的问题之一，而 bcrypt 仍然值得麻烦。但我想知道我是否在这里遗漏了一些明显的东西？微妙的东西？或者那里的任何人都可以指向一个众所周知的网站，该网站运行整个服务器群只是为了他们网站的身份验证部分？

Answer 1

即使您将 bcrypt 调整为仅占用 1/1000 秒，这仍然比简单的散列要慢得多——一个快速而肮脏的 Perl 基准测试表明，我的不太新的计算机可以计算大约 300,000 个 SHA-256 散列每秒。

是的，1000 和 300,000 之间的差异只有大约 8 位，但这仍然是 8 位的安全余量，否则您将不会拥有，而且这种差异只会随着 CPU 速度的提高而增加。

另外，如果您使用 scrypt代替 bcrypt，即使迭代次数减少，它也将保留其内存硬度属性，这仍然会使其难以并行化。