On 10/31/05, loki tiwaz <loki_tiwaz@xxxxxxxxxxx> 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.