in my opinion this just highlights the absurdity of the concept of password
security on the web, period. in this situation, tor users are vulnerable to
tor nodes sniffing the plaintext passwords being sent to the webserver,
which is an issue for tor users anyway. However, compromising network nodes
in proximity to the wikipedia server could have the same effect. And the
same applies to any website.
Security is not binary. I put a (slightly) higher level of trust
in the ISPs between myself and Wikipedia than I put in some random
person running a Tor exit node. Only slightly, though. The
reality is that it's not that huge of a deal if someone finds out my
Wikipedia password. In fact, in some ways it's a feature in that
I can repudiate any edit made using my account.
If the server uses https for password authentication (as is used on
hotmail), there is little risk of this occurring. But there is still an
opening, which is the man in the middle attack, where a node between the
server and the routes out to the rest of the internet could be compromised
as well, and the https security becomes null and void.
I was under the impression that a man-in-the-middle attack would
require obtaining a certificate signed by one of the default
certificate agencies with the same domain name as the destination
server. Now every once in a while bugs will pop up which might
trick a browser into not properly making this check, but that's a bug
in implementation not a bug in the design.
I should also note that any Tor exit node can perform a man-in-the-middle attack in addition to just sniffing passwords.
So, in essence, the problem here is not just something you find with
wikipedia, it applies to every site, encrypted or not. Encryption is a layer
of protection which is difficult but not impossible to violate. All good
security systems include two layers of protection, and the simplest and
already widely used method for ppp connections should be used, challenge
authentication protocols. In this case the simplest way to implement it is
to send a challenge code with the page, and when the 'submit' button is
clicked, a _javascript_ program hashes the password, and then hashes the
password hash with the challenge code. the server then will only
authenticate the user if the stored password hash, hashed with the sent
challenge code, matches the code sent by the user.
Unless you happen to check the _javascript_ source every time you type in
your password, this would still be subject to a man-in-the-middle
attack. Using client certificates which are distributed using a
pre-established secure channel would probably be the best security, but
installation is not that user-friendly and roaming is difficult (of
course, you might say that it's a security risk to use Wikipedia from a
coffee shop in the first place, but I think you're overvaluing the
importance of absolute security on a site that anyone can edit).
Using this _javascript_ hashing scheme has one drawback in that it
requires the unencrypted password to be stored in the database.
This isn't a drawback if you look at security in a binary way, because
someone who has access to modify the server could get the unencrypted
password anyway, but it would make it somewhat easier especially for
someone who only has access to the database.