Wikipedia and Tor - a solution in the works?

[loki tiwaz]

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 at inbox.org>
>Reply-To: or-talk at freehaven.net
>To: or-talk at freehaven.net
>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/