I'm going to pick on Neil a little, because I know he can take it, but it applies to just about everybody else in this thread.
For shame. On 10/26/11 9:13 AM, Neil Harris wrote: > On 26/10/11 13:03, Steve Summit wrote: >> William Allen Simpson wrote: >>> This replacement password is much more easily guessed. >>> The account could have been stolen within minutes or hours. >> Is this true? (Yes, I know that a fast machine can try zillions >> of passwords per hour in theory, but for a reasonably designed >> system, certainly not in practice.) >> >>> Please update the password generator to use at least 17 characters, >> That seems like far too many. >> > > In practice, that password is probably much stronger than most users' > real passwords. > Please don't conflate user choices with our choices. Since the password is generated on demand, the adversary *knows* something was generated and sent. That's quite different than attacking a random user. It is our choice to send a weak password in email -- a bad choice. > It might perhaps be worth adding one more character, Really, how *hard* is it to generate a longer string? > , but the simplest > way to increase security on this would be to just put a limit on the > number of reactivation attempts for that particular password. > Why would this be simpler? Seems like a lot more code to me. > 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. ;-) > Automatically expiring that temporary password after say, 10 failed > reactivation attempts, would reduce the probability of successfully guessing > that particular password to around 3 x 10^-12 -- probably safe enough for > wiki purposes. > No, that's not correct math. Worse, that would generate a denial of service attack all on its own. All the adversary has to do is send periodic attempts to lock somebody out of their own account. Moreover, what problem does that solve? > Based on this, I don't think it's likely to be nearly as much of a problem as > brute-force attacks on ordinary login passwords that go for the "low-hanging > fruit" of users with passwords like "1234" or "password1". > This is the lowest *possible* hanging fruit. We're generating it! > Even these can be substantially mitigated by a mixture of per-account and > per-client-IP-address throttling, and CAPTCHAs. > While it would be nice to have better user password checking, and require all login sessions to be over HTTPS, and not use cookies to identify sessions, and many other desirable improvements -- this is the simplest and easiest thing I can imagine! > If there's one measure I'd like to see that isn't (as far as I know) yet > implemented, it would be to require admins and other privileged users to set > strong passwords, perhaps initially by Javascript-based warnings, and later > by locking out those accounts completely, after a warning period of perhaps > one year. > Now, that seems much too long a time. I'd make it a prerequisite for being an administrator at all! _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
