Wikipedia and Tor - a solution in the works?

[Anthony DiPierro]

On 10/31/05, loki tiwaz <loki_tiwaz at hotmail.com> wrote:
>
> 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.

 Well, you see security as binary, I don't. I look at the chances that
something is going to happen, and by increasing the number of people who can
break the security from a relatively small number (I happen to live in the
same city as the Wikipedia servers) to potentially anyone in the world, I
see that as a negative thing. Apparently you don't.

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

 Yes, it's possible that someone could steal the private key of the service
who couldn't otherwise steal the information directly. And that same person
might happen to be able to mount a man-in-the-middle attack. But I think the
chances of that are relatively slim compared to the chances of them simply
attacking the service directly.

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

 You've simply changed the password from one to another. This might be
useful if the original password was was used on multiple sites, but
otherwise it's rather useless, because the original password is no longer
needed to access the site, only the hashed password (and some client-side
tweaks to the javascript).

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.

 You don't seem to understand how a man-in-the-middle attack works. In this
type of attack the data going from the server to the man-in-the-middle is
different from that going from the man-in-the-middle to the client. The
man-in-the-middle would simply turn off the hashing of the password in the
javascript presented to the client. They'd then get a copy of the original
plaintext password and could use that to generate the hashed password to
access the site by emulating the javascript presented to them from the
service.

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

 Yes, performing a man-in-the-middle attack over SSL is difficult. But
that's why simply providing the password over that SSL connection is usually
acceptable. All the fancy hashing amounts to essentially no security against
any type of attack. This presumes of course that users don't use the same
password for multiple sites, and that they use passwords that are difficult
to guess. But if they don't, that's their problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20051031/f72cdfad/attachment.htm>