If however our hashes have not been disclosed, all of that is hypothetical. In that case, network bandwidth and the overhead of your application is the limiting factor when bruteforcing.

There are many well-known mechanisms for defeating front-of-house attacks that are far, far more effective than password rules:

• Insert an obligatory 5 second delay between accepting the password and the acceptance/rejection.

  Even with 1000 concurrent attack vectors, a minimal 4-char password of upper-case-alpha only will require 2 weeks on average to crack.

• Start with a 1 second delay and double it after each failure.

  Even a single character password will take an average of 1 year to find.

• Require email contact after 3 failed attempts.

  Possibly the most effective.

To guard against GPU bruteforcing of disclosed hashes, the only practical solution (as people can hardly be convinced to use different 20+ character passphrases everywhere) is key stretching. If you use so many hashing rounds your machine takes 100 ms to calculate a hash, that doesn't hurt you much

(To the emboldened bit): Actually, they can.

The simple fact is that using the same 20-char pass-phrase everywhere is far more secure than using a different 8 character passwords at each site. And far easier to remember than multiple passwords.

And, if the information was out there and people would take notice, coming up with a single, memorable pass-phrase is actually quite easy:

'the quick brown fox', 'every good boy deserves favour', 'nine eleven two thousand and one'. 'marge, bart, and lisa', 'red orange yellow green blue indigo violet', ...

Even if the hash of your one passphrase is disclosed somewhere, cracking will take so long you'll be dead before you are vulnerable on other sites.