【发布时间】：2012-03-30 20:46:51
【问题描述】：
我加入 bcrypt 潮流已经有一段时间了，但我无法回答一个简单的问题。
假设我在美国有一个相当成功的网站。大约有 100,000 名活跃用户，每个人的活动模式需要在典型的美国工作日期间平均需要 2 到 3 次身份验证尝试（如果包括时区，则为 12 小时） .即每天 250,000 个身份验证请求，或每秒大约 5.8 个身份验证。
bcrypt 的一个巧妙之处在于您可以对其进行调整，以便随着时间的推移它可以像硬件一样进行扩展，以保持领先于破解者。一个常见的调整是让它每次哈希创建花费超过 1/10 秒......假设我将它设置为每个哈希 0.173 秒。我之所以选择这个数字，是因为碰巧每个散列 0.173 秒相当于每秒大约 5.8 个散列。换句话说，我假设的 Web 服务器实际上是把所有的时间都花在了验证用户的身份上。没关系实际做任何有用的工作。
要解决这个问题，我必须要么调低 bcrypt 方式（不是一个好主意），要么获得一个专用服务器来进行身份验证，仅此而已。现在想象一下，该网站增长并增加了另外 100,000 个用户。突然我需要两台服务器：同样，除了身份验证什么都不做。甚至不要开始考虑负载高峰，因为您一天中都有轻松和忙碌的时期。
正如我现在所看到的，这是最好的问题之一，bcrypt 仍然值得麻烦。但我想知道我是否在这里遗漏了一些明显的东西？微妙的东西？或者那里的任何人实际上都可以指向一个运行整个服务器场的知名网站，只是为了他们网站的身份验证部分？
【问题讨论】：
-
如果你有钱，它是可行的。一些站点不认为完全 HTTPS 是可行的，因为所需的带宽和处理能力增加了几个百分比。但其他大型站点执行仅 HTTPS 策略没有问题。这取决于您的预算和优先事项。
-
这不是一个专门用于身份验证的服务器：它是一个核心。
-
@Peter - 它不仅仅是一个核心。否则，黑帽可能只会在显卡问题上抛出更多并行硬件。
-
他们可以。在它们的核数超过键空间大小之前，拆分键空间是加快搜索速度的明显方法。
-
@PeterTaylor 是对的。 bcrypt 的设计使得一个 crypt 操作的计算不能并行化（由于严重的数据依赖性）。您的网络服务器只需执行多个不同的 crypt，这些 crypt 可以分发到许多便宜的 cpu 内核。
标签： security performance authentication passwords scalability