in reply to Re^2: Password strength calculation
in thread Password strength calculation

I think you're worrying about the wrong kind of attacks

I'm not worrying about anything. There is no such thing as "the wrong kind of attack". People being people, will reuse the same passwords for different sites.

So, you hack a few "low risk" sites, grab a few thousand userid/password combos and then try them on your real target.

Technically rejecting anything under 6 characters or so also does nothing else but reduce the number of possibilities but that's just the possibilities that will usually be tried first anyway

If I know your site doesn't accept passwords of less that 6 characters, that is somewhere between 782,757,789,696 and 308,915,776 permutations , depending upon what other silly restrictions you have in-place, that I don't have to try. Why make my life easy?


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Replies are listed 'Best First'.
Re^4: Password strength calculation
by mbethke (Hermit) on Jan 20, 2012 at 21:49 UTC
    If I know your site doesn't accept passwords of less that 6 characters, that is somewhere between 782,757,789,696 and 308,915,776 permutations , depending upon what other silly restrictions you have in-place, that I don't have to try. Why make my life easy?

    Using uppcercase, lowercase and digits you have 62^6=56,800,235,584 combinations---a whopping 0.000000002% of the remaining search space if we assume an upper limit of 12 characters. That's like making your work easy[tm] by shaving 50 µs off your 8 hour working day :)

    This only becomes relevant anyway in the worst case of someone getting to your password DB. Nobody's gonna try that many combinations online; under the completely unrealistic assumption of 1000 parallel connections that each try 10 passes a second it would still take over two months. What people (and password crackers like John the Ripper) do first is take a dictionary, try that, then reverse, substitute some letters with more or less obvious digits, rinse and repeat. Password policies are supposed to keep people from using "dog", "johN" or "m0mmy" as passwords that indeed have a chance of being found by such attacks. They save an attacker a negligible amount of time if he's really going to try all combinations but not having any saves him close to 100% because he can count on some people stupidly choosing a dictionary word or the like.

      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!

      Here we have clusterable twin-GPU AWS instances for $2.10 per hour. So for less that $20 you can crack 8-char passwords, from their hashes in an hour.

      And the proof it's possible: German 'hacker' uses rented computing to crack hashing algorithm - Brute force PAYG hack attack cracks SHA1 hashes – for $2

      The only effective defence is increasing the possibilities.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        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.