in reply to Re^5: Password strength calculation
in thread Password strength calculation
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^7: Password strength calculation
by BrowserUk (Patriarch) on Jan 21, 2012 at 02:39 UTC | |
by mbethke (Hermit) on Jan 21, 2012 at 05:23 UTC | |
by BrowserUk (Patriarch) on Jan 21, 2012 at 07:23 UTC | |
by mbethke (Hermit) on Jan 21, 2012 at 18:48 UTC | |
by BrowserUk (Patriarch) on Jan 21, 2012 at 21:04 UTC | |
| |
by stonecolddevin (Parson) on Jan 25, 2012 at 17:42 UTC | |
by BrowserUk (Patriarch) on Jan 25, 2012 at 20:03 UTC | |
by stonecolddevin (Parson) on Jan 25, 2012 at 20:22 UTC | |
by BrowserUk (Patriarch) on Jan 25, 2012 at 22:03 UTC |