我已经在加入了一段时间了，但是我在回答一个简单的唠叨问题时遇到了麻烦。
想象一下，我在美国有一个相当成功的网站..大约有100,000名活跃用户，每个活动模式在一个典型的美国工作日（包括时区12小时）内平均需要2到3次身份验证尝试。这是每天250,000个身份验证请求，或每秒约5.8个身份验证。
关于bcrypt的一个巧妙的事情就是你调整它，以便随着时间的推移它随着硬件的扩展而扩展，以保持领先于破解者。一个常见的调整是让每个哈希创建时间超过1/10秒...让我说每个哈希值达到.173秒。我之所以选择这个数字，是因为每个哈希值.173秒就达到了每秒约5.8次哈希。换句话说，我假设的Web服务器实际上花费了所有时间，除了验证用户之外什么都不做。别介意做任何有用的工作。
要解决这个问题，我必须调低bcrypt方式（不是一个好主意）或者只是为了进行身份验证而得到一个专用服务器，而不是别的。现在假设该网站增长并增加了另外100,000个用户。突然间我需要两台服务器：再次，除了身份验证之外什么都不做。甚至不要开始考虑负载峰值，因为你整天都有光照和繁忙的时期。
正如我现在所看到的，这是一个很好的问题之一，而且bcrypt仍然值得一试。但我想知道我是否错过了一些明显的东西？有些微妙吗？或者，那里的任何人都可以指向一个众所周知的网站运行整个服务器场只是为了他们网站的身份验证部分？
答案 0 :(得分：5)
即使你只调整bcrypt，比如1/1000秒，这仍然比简单的散列慢一点 - 一个快速而肮脏的Perl基准测试表明我不太新的计算机可以计算出大约300,000个SHA每秒-256个哈希。
是的，1000和300,000之间的差异只有大约8位，但这仍然是你没有的8位安全边际，并且这种差异只会随着CPU变快而增加。
此外，如果使用scrypt而不是bcrypt，即使迭代次数降低，它也将保留其内存硬度属性，这仍然会使得粗暴强制并行化更难。