Once passwords are hashed, (and no one stores unhashed passwords right!), the stored hashes all end up the same length regardless of the length of the input. So any reduction in the possibilities just makes things quicker. And quicker, just means cheaper... Here we have a (single) gpu cracking 8-character hashed (NTLM) passwords that would take 1 year using a fast cpu, in 18 hours. At a rate of 3.334 billion passwords per second!
I'm well aware of current cracking capabilities (and the relative ease of calculating NTLM hashes BTW). But to do that, an attacker has to get at the hashes first, which assumes he's hacked your application already. Only in that case do make his work easier and cheaper: if we assume the conditions of your example and only allow 7- or 8-character passes, it's not 0.000000002% but 0.025%. So on his 1-hour cracking session he's saved 0.9s or 0.5 cents.
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. In that case, only simple dictionary attacks have a chance of succeeding. And that's what is actually going on---just watch auth.log on any internet-facing server with SSH enabled!
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. A GPU may do it it 100 µs or whatever then but that's still impractically slow for bruteforcing.
In reply to Re^6: Password strength calculation
by mbethke
in thread Password strength calculation
by cavac
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |