<div><span class="gmail_quote">On 10/31/05, <b class="gmail_sendername">loki tiwaz</b> <<a href="mailto:loki_tiwaz@hotmail.com">loki_tiwaz@hotmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">i think it would be stupid to trust any unknown entity whether official or<br>not in any case. in some ways official entities are less trustworthy because
<br>they can be made to bend over by possibly immoral law enforcement. the only<br>way to trust is to build up a relationship of ongoing fulfillment of trust.</blockquote>
<div> </div>
<div>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.
<br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">yes, i had already thought about this one too, and both constitute security<br>issues in tor which should be considered. the use of ssl allows a
<br>significant degree of safety against password sniffing, but, as you said,<br>there is some scope for spoofing the browser, but it's a pretty narrow one,<br>the CAs are unlikely to sign a certificate for an ip address which which is
<br>already registered with them. But if the server operators of a site haven't<br>been completely careful with their security the server keys could be taken<br>and used to mount just such attacks, so man in the middle attacks mainly
<br>hinge upon the compromise of the remote site's security practises.</blockquote>
<div> </div>
<div>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.
</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">you did not read me correctly. the password hash is stored on the server,<br>not the password, the password must be hashed on the browser, and then the
<br>hash hashed with the challenge code. it is not possible to break this type<br>of authentication unless the hash algorithm is weak.</blockquote>
<div> </div>
<div>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).
</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">i have yet to encounter a competent authentication system which does not<br>store passwords as hashes (although as is well known, the md4 lmhashes in
<br>windows are weak), this is the reason behind password recovery systems. the<br>javascript must accurately reproduce the combined hash of the password hash<br>and the challenge code, which means the server will not authenticate if this
<br>is not done correctly, so the javascript code is not a weak point in the<br>security.</blockquote>
<div> </div>
<div>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.
<br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">if it is compromised this is again the fault of the security<br>practises of the server operator. the use of the challenge code and combined
<br>hash is not breakable without compromising the server, and this is the least<br>of the potential attacks that could be mounted if one can compromise the<br>server anyway. without ssl on the authentication system it is facile to
<br>mount a man-in-the-middle attack by injecting code into the javascript to<br>send the plaintext elsewhere (especially from a tor exit node, or an<br>upstream node from the exit node), but with ssl the man-in-the-middle attack
<br>takes compromising two security systems if ssl is used, not just one, and<br>both of these attack vectors require lax security on the server operator's<br>part, and if the server is compromised, as i said, this is the least of the
<br>potential attacks that could be undertaken (and being that there is serious<br>legal consequences arising from having a rooted public server, it is<br>unlikely that any serious operator would permit this to happen)</blockquote>
<div> </div>
<div>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.
</div></div>