Wikipedia and Tor - a solution in the works?

[Anthony DiPierro]

On 10/31/05, loki tiwaz <loki_tiwaz at hotmail.com> wrote:
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20051031/55a520e0/attachment.htm>