bcrypt对于大型网站是否可行？

Question

我一直在加入bcrypt一段时间,但是我在回答一个简单的唠叨问题时遇到了麻烦.

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

关于bcrypt的一个很好的事情就是你调整它,以便随着时间的推移它随着硬件的扩展而变化,以保持领先于破解者.一个常见的调整是让每个哈希创建时间超过1/10秒...让我说每个哈希值达到.173秒.我之所以选择这个数字,是因为每个哈希值.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,即使迭代计数降低,它也将保留其内存硬度属性,这仍然会使得粗暴强制并行化更难.