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


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/