[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: Wikipedia and Tor - a solution in the works?

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.

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.

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.

challenge authentication protocols allow a high degree of security over an unencrypted connection, but adding encryption to it creates a double layer for which there is a very thin margin of possibility of compromising of the security of the user login.

as for the problem of new users being registered to permit further attacks on the system, it should be sufficient to a) throttle new user logins on the same ip in the tor exit node addresses and b) use a visual confirmation system, and c) require the use of email confirmation. These sorts of rules must be applied to any high volume website in any case, and close up most of the possibilities for automated user registrations by trolls.

Banning a set of ip addresses is an ignorant and futile method of ensuring security. trolls could set up a number of tor exit nodes, modify their tor client to select exit nodes from their range of tor exit nodes in their control, and have the tor nodes only wake up when a special code is sent with the packet which signifies their use, and then you have a situation where ip addresses which are not in the regular tor exit node cloud can proxy tor connections and then just as suddenly disappear from the tor cloud and thus bypass the ip blocking protection without stopping the user from using tor. i'm sure a modification of a trojan system could produce an unlimited range of short-lived tor exit nodes to use for this purpose, and blocking tor addresses is just asking for this to happen. and i should point out that this strategy, and similar strategies (for example tunneling from the tor exit node to another anonymity/proxy system, even just open proxies) applies to other ways of abusing the tor network.

ultimately the onus rests on the website to come to grips with the fact that tor is just one of many ways to protect source ip address, and there is many ways to compromise this. the only protection is strong authentication systems and smart user registration systems.

From: Anthony DiPierro <or@xxxxxxxxx>
Reply-To: or-talk@xxxxxxxxxxxxx
To: or-talk@xxxxxxxxxxxxx
Subject: Wikipedia and Tor - a solution in the works?
Date: Sat, 29 Oct 2005 14:42:36 -0400

Jimmy Wales proposed what he described as a "simple solution to the problem
of Tor users being unable to edit Wikipedia." Here it is:

"trusted user -> tor cloud -> authentication server -> trusted tor cloud ->
wikipedia"

"untrusted user -> tor cloud -> authentication server -> untrusted tor cloud
-> no wikipedia"

David Benfell responded "So they want us to do their authentication for
them. Wrong answer." I think this points out exactly the problem with Mr.
Wales' proposal, but it's perhaps not clear to everyone why.

First, let me try to understand exactly what it is Mr. Wales is proposing.
Someone, presumably someone not affiliated directly with Wikipedia, is
supposed to run an "authentication server". Presumably this authentication
server will establish pseudonymous accounts with some mechanism for
authentication (for simplicity let's say username/password). Some mechanism
will be used to tie edits made to Wikipedia to the account username, and
upon complaints coming from Wikipedia that account will be disabled. Now,
since the authentication server must not know the true identity of the
trusted user (since that would completely destroy the anonymity), there
needs to be a way for an untrusted user to become a trusted user. But to
limit abuse where a single person creates many accounts, some mechanism must
be implemented at the authentication server to throttle the creation of new
pseudonymous accounts.

Let me now explain why the "trusted tor cloud" would be very difficult to
implement, as well as why it is essentially useless. The difference between
a "trusted user" and an "untrusted user" is specific to the application.
What Wikipedia considers bad behavior does not coincide with what someone
else might consider bad behavior. While there might be some actions which
are fairly universally accepted as bad behavior, it is likely that Wikipedia
will not accept merely limiting these behaviors. What I'm saying in essense,
is that the "authentication server" would have to be geared specifically to
Wikipedia. For this reason, the trusted tor cloud would likely be very
small, and it would be quite simple to determine the location of the
authentication server. So you might as well remove the "trusted tor cloud"
completely, and simply have the authentication server connect directly to
Wikipedia.

So now, we have "trusted user -> tor cloud -> authentication server ->
wikipedia". The Tor cloud between the authentication server and Wikipedia
was difficult to implement and essentially useless, so we dropped it.
Instead the authentication server connects directly to Wikipedia using a
single IP address. This could be implemented without too much work on the
part of Wikipedia, they'd essentially only have to agree not to ban the IP
address of the authentication server (at least not for a very long period of
time), and to send information about any bad behavior to that server. In
theory you could even run it as a Tor hidden service, increasing the
anonymity (especially since Wikipedia doesn't offer https).

If Wikipedia would agree to this, it wouldn't be too hard to set up. But it
would make the most sense for Wikipedia to run the authentication server
itself! Wikipedia already has pseudonymous accounts set up, after all.

To be clear, for those who aren't familiar with the way Wikipedia implements
blocking, users, even users that have established accounts on Wikipedia for
years, cannot edit Wikipedia if the IP address they are using is blocked
(even admins are blocked from editing, though they are able to remove the IP
block). There is a proposal on Wikipedia to correct this, at
http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy_proposal . Almost
everyone supports it, the only real question is what mechanism to use to
throttle/limit the creation of new accounts. It seems to me that this is a
good implementation of "trusted user -> tor cloud -> authentication server
-> wikipedia", where the authentication server is run by Wikipedia itself.
What would be a good additional feature would be for Wikipedia to offer a
Tor hidden service to use to connect to Wikipedia. This is especially true
since Wikipedia passwords are passed in plaintext over http and thus could
be snooped by an exit node.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/