title: What can be done to protect against brute-force of compromised password databases?
body: <p>In light of the recent data breach at Blizzard I want to ask about brute-force and salted-hash password storage.</p>
  
  <p><a href="http://arstechnica.com/security/2012/08/hacked-blizzard-passwords-not-hard-to-crack/" rel="nofollow">Ars Technica has a good article</a> on why even the salted-hash passwords that Blizzard stores can be cracked in short order.</p>
  
  <p>Because of the salting and hashing used, we know that a brute force attack is the only viable way to crack the "complicated" passwords (dictionary/plain-word passwords are trivial)... However Ars Technica makes a good point that the vast improvement in computational power (both local and in the cloud) makes brute-force cracking more viable.</p>
  
  <p>For a website, <a href="http://www.codinghorror.com/blog/2009/01/dictionary-attacks-101.html" rel="nofollow">Jeff Atwood notes</a> that forcing delays in authentication attempts can realistically thwart brute-force attempts.... But in the case of the Blizzard breach, hackers have physical control of the DB, so no such accessibility limit can be imposed.</p>
  
  <p>Consequently, <a href="http://www.codinghorror.com/blog/2005/07/passwords-vs-pass-phrases.html" rel="nofollow">Jeff also recommends pass-phrases</a> because of the increased entropy facing a brute-force attacker.... But this, too, will eventually effectually fade as computational power becomes greater and more accessible. </p>
  
  <p><strong>So the question is: What brute-force protection schemes can be implemented that aren't vulnerable due to increasing computation power?</strong></p>
  
  <p>Two-stage authentication is often considered, but I've heard that some of these algorithms are also being broken, and a physical authenticator has a likely static algorithm, so once it's cracked all users would be vulnerable.</p>
  
  <p>What about scheduled rolling salts that apply to the entire authentication DB? This would add a lot of overhead but seems like it would secure even in cases where the physical DB is leaked. </p>