On Sun, 30 Oct 2011 05:34:02 -0700, Thomas Dalton thomas.dalton@gmail.com wrote:
On Oct 30, 2011 11:29 AM, "William Allen Simpson" < william.allen.simpson@gmail.com> wrote:
On 10/26/11 9:13 AM, Neil Harris wrote:
Assuming the seven-character password given, "YH2MnDD", uses the
character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
I really wish folks would at least read a Wikipedia article before making such calculations. :-(
No, you've listed the number of combinations, not the entropy.
No, 40-bits of strength means 2**20 attempts on average. Same order of magnitude as WEP. You remember WEP, the security designed to be easily crackable?
https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
In 2005, a group from the U.S. Federal Bureau of Investigation gave a demonstration where they cracked a WEP-protected network in 3 minutes using publicly available tools.
Or, maybe, perhaps, you might trust that a well-known long-time security professional is telling you the generated password is too weak. ;-)
If you are going to be so insulting, please at least try and be right... You could start by reading the articles you are telling other people to read.
For a random sequence of characters, the entropy is just the base-2 log of the number of combinations, so there is nothing wrong with just calculating the number of combinations. Converting to entropy just makes it easier to compare two passwords drawn from different character sets.
WEP is flawed because it encrypts different parts of the message using related keys, not because it is susceptible to a brute force attack on the password. It is completely irrelevant to our discussion.
To get the average number of attempts, you half the number of combination, you don't square root it. With 40 bits, the average is 2^39 attempts, not 2^20.
And to top it off WEP is a local attack, one where you can brute force at a much higher rate than you can over the latent Internet hitting servers as fast as they can handle your requests.
I do take back my estimate of it taking 1.14 centuries at 1000 guesses/second to brute force the entire password space. That was calculated on the basis of normal passwords which are length-variant as well, but the one we generate is fixed-length so that doesn't apply.
Looking at our code we generate a fixed-length random password: - length 7 or the minimum password length, whichever is larger (minimum password default seams to be 1 so it's usually 7) - one character is always a digit, which character is a digit is random - All other characters are [a-zA-Z]
A digit has 10 possibilities, the alphabet has 26 characters which combined with an upper-lower set is (26*2) = 52 possibilities.
So for one digit placement (ie: #XXXXXX) the number of possible passwords is (10 * 52^6) (ie: [10, 52, 52, 52, 52, 52, 52]), for all 7 digit placements that is multiplied by 7.
(10 * 52^6) * 7 = 1383942676480
So there are 1383942676480 (~1.38 x 10^12) possible passwords to generate.
Going back to the estimate of a theoretical brute force attack able to guess 1000 passwords/second without any rate limiting, that will take 8.95 years to go through the entire password space. If I understand Thomas Dalton's note about halving the number of combinations then that would be an average of 4.5 years.
Given that we expire a temporary password within 7 days after generating it at 1000 passwords/second an attacker will be able to go through (7 * 24 * 60 * 60 * 1000) = 604800000 potential passwords, which when divided by the number of possible passwords is ((7 * 24 * 60 * 60 * 1000) / (10 * 52^6)) = 0.3% of the possible passwords.
And of course, we rate limit password guesses when a cache is available. Though making that a 'we always rate limit password guesses' would be a good idea.
Since the strength of that is already good enough I'd still opt to instead work on the less simple task of replacing our randomized 'passwords' with a generated token embedded in a link.