On Sun, 30 Oct 2011 05:34:02 -0700, Thomas Dalton <[email protected]> wrote:
> On Oct 30, 2011 11:29 AM, "William Allen Simpson" < > [email protected]> 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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
