On 10/31/05, <b class="gmail_sendername">loki tiwaz</b> <<a href="mailto:loki_tiwaz@hotmail.com">loki_tiwaz@hotmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
in my opinion this just highlights the absurdity of the concept of password<br>security on the web, period. in this situation, tor users are vulnerable to<br>tor nodes sniffing the plaintext passwords being sent to the webserver,
<br>which is an issue for tor users anyway. However, compromising network nodes<br>in proximity to the wikipedia server could have the same effect. And the<br>same applies to any website.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If the server uses https for password authentication (as is used on<br>hotmail), there is little risk of this occurring. But there is still an
<br>opening, which is the man in the middle attack, where a node between the<br>server and the routes out to the rest of the internet could be compromised<br>as well, and the https security becomes null and void.</blockquote>
<div><br>
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.<br>
<br>
I should also note that any Tor exit node can perform a man-in-the-middle attack in addition to just sniffing passwords.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, in essence, the problem here is not just something you find with<br>wikipedia, it applies to every site, encrypted or not. Encryption is a layer
<br>of protection which is difficult but not impossible to violate. All good<br>security systems include two layers of protection, and the simplest and<br>already widely used method for ppp connections should be used, challenge
<br>authentication protocols. In this case the simplest way to implement it is<br>to send a challenge code with the page, and when the 'submit' button is<br>clicked, a javascript program hashes the password, and then hashes the
<br>password hash with the challenge code. the server then will only<br>authenticate the user if the stored password hash, hashed with the sent<br>challenge code, matches the code sent by the user.</blockquote><div><br>
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).<br>
<br>
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.</div></div>