Aryeh Gregor <Simetrical+wikilist at gmail.com> wrote:
As I noted above, there are hash functions whose security is provable based on the exact same assumptions used to prove security of various popular asymmetric encryption schemes. As I also noted above, there are problems with naively trying to use public-key encryption instead of hash functions. It makes more sense to just use known-secure hash functions directly instead of trying to twist public-key encryption to our needs, if we're that worried about Whirlpool (et al.) being broken anytime soon.
Password length disclosure can be overcome by padding all password inputs to the maximum length allowed, as you noted. Practically, though, a scheme like this adds an extra roadblock (if the key is not just stored in the database) which an attacker must overcome. Assuming even basic conscientiousness on the part of the administrator this would add a non-trivial extra compromise for the attacker to pull off. Getting all Wikipedia password hashes and going to work on them is just one data dump script bug away, though.
For what it's worth, even ancient and thoroughly-broken hash functions like MD4 don't have readily-usable preimage attacks.
These attacks (typically aimed at digital signatures) do not allow themselves the luxury of assuming the extremely small pre-image space that is typical for user-entered passwords, though. This makes brute-force attacks feasible and the
only practical constraint on the attacker becomes the hash function's run time.
Several years ago MD5 was brute-forced on the credit card number space in only a couple of days. Credit card numbers have ~10^16 permutations; even assuming strong passwords (upper and lower case letters, digits, and special characters) that is
only ~70^10 for a "very strong" 10 digit password, or ~10^18 and so of about equal complexity.
Mediawiki luckily already salts its password hashes with the user name, which makes site-wide brute force attacks impractical, though not targeted account brute force attacks. Given the stakes involved this is probably sufficiently strong, though in other contexts compromising a single account may be unacceptable. And I'm sure one could perform some interesting social engineering-based attacks as "User:Jimbo Wales" :-)
On Fri, Aug 20, 2010 at 7:38 PM, Jonathan Leybovich jleybov@yahoo.com wrote:
These attacks (typically aimed at digital signatures) do not allow themselves the luxury of assuming the extremely small pre-image space that is typical for user-entered passwords, though. This makes brute-force attacks feasible and the
only practical constraint on the attacker becomes the hash function's run time.
Brute-force attacks and preimage attacks are entirely separate. Any hash function is vulnerable to a brute-force attack, and they're all more or less equally vulnerable -- you can only gain a couple orders of magnitude advantage at best, and only by making your own code execute slower and betting that it will inconvenience the attacker more than you. A preimage attack is entirely separate, and well-known hash functions (even totally obsolete ones like MD4) generally aren't vulnerable to them in practice.
Attacks aimed at digital signatures are generally neither brute-force nor preimage, but rather collision attacks. This is why MD5 is currently unacceptable for digital signatures, but fine for password hashes. There are known collision attacks, but no known preimage attacks, and it's no more or less susceptible to brute force than any other hash.
On Sat, Aug 21, 2010 at 2:17 AM, MZMcBride z@mzmcbride.com wrote:
Facebook has been having issues with compromised accounts that send out spam, either through Facebook messages or Wall posts. This doesn't completely refute your point, but it is a pretty good example of bad users going after readily available, free-to-make accounts in order to misuse them.
Because Facebook accounts can send messages that look like they're from someone you know, since they have a built-in friends list and are meant to be used for chatting. On a wiki that anyone could edit, 1) there would be little advantage in using an actual account rather than doing it anonymously (perhaps adding false signatures -- most people won't check the history); and 2) the spam would all be public, so when the first compromised post is discovered it would all be reverted.
Put another way -- there's a reason people do this kind of thing on Facebook (and IM, etc.), but demonstrably do *not* do it on Wikipedia.
It would be much easier and convenient to check the password upon login.
Users might not log in for a month after promotion.
So that a local wiki admin can add the custom JavaScript as a gadget and the preference can ultimately move from one tab to another? :-)
Yes, because then it's not our problem. ;)
On Sat, Aug 21, 2010 at 4:15 AM, Liangent liangent@gmail.com wrote:
See this: https://bugzilla.mozilla.org/show_bug.cgi?id=542689
That's the least of it. China doesn't need to own a root CA to forge certificates. All you need is one CA that's based in China or does enough business there. If the government demands a forged certificate, the CA will be in no position to refuse. I've heard that there are Western CAs that openly advertise that they'll provide forged certificates if requested by the government as part of a legitimate police investigation. TLS based on the current CA system is worthless against a moderately large government.
TLS over SRP, or at least DNSSEC, would be better. But it's still not going to be like in the movies, where some seditious underground movement can stay completely hidden from a powerful government by means of 1337 h4x. Governments don't have to play fair, and there are tons of technical and non-technical ways they can beat you: http://xkcd.com/538/. If we're going to stay in the realm of sanity, we need to focus on foiling attackers of reasonably limited means, such as a criminal gang with access to a large botnet -- not a government.
wikitech-l@lists.wikimedia.org