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.
>
>
>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.

i think it would be stupid to trust any unknown entity whether official or 
not in any case. in some ways official entities are less trustworthy because 
they can be made to bend over by possibly immoral law enforcement. the only 
way to trust is to build up a relationship of ongoing fulfillment of trust.

>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.

yes, i had already thought about this one too, and both constitute security 
issues in tor which should be considered. the use of ssl allows a 
significant degree of safety against password sniffing, but, as you said, 
there is some scope for spoofing the browser, but it's a pretty narrow one, 
the CAs are unlikely to sign a certificate for an ip address which which is 
already registered with them. But if the server operators of a site haven't 
been completely careful with their security the server keys could be taken 
and used to mount just such attacks, so man in the middle attacks mainly 
hinge upon the compromise of the remote site's security practises.

>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.

you did not read me correctly. the password hash is stored on the server, 
not the password, the password must be hashed on the browser, and then the 
hash hashed with the challenge code. it is not possible to break this type 
of authentication unless the hash algorithm is weak.

i have yet to encounter a competent authentication system which does not 
store passwords as hashes (although as is well known, the md4 lmhashes in 
windows are weak), this is the reason behind password recovery systems. the 
javascript must accurately reproduce the combined hash of the password hash 
and the challenge code, which means the server will not authenticate if this 
is not done correctly, so the javascript code is not a weak point in the 
security. if it is compromised this is again the fault of the security 
practises of the server operator. the use of the challenge code and combined 
hash is not breakable without compromising the server, and this is the least 
of the potential attacks that could be mounted if one can compromise the 
server anyway. without ssl on the authentication system it is facile to 
mount a man-in-the-middle attack by injecting code into the javascript to 
send the plaintext elsewhere (especially from a tor exit node, or an 
upstream node from the exit node), but with ssl the man-in-the-middle attack 
takes compromising two security systems if ssl is used, not just one, and 
both of these attack vectors require lax security on the server operator's 
part, and if the server is compromised, as i said, this is the least of the 
potential attacks that could be undertaken (and being that there is serious 
legal consequences arising from having a rooted public server, it is 
unlikely that any serious operator would permit this to happen)

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