There are no passive-only attackers. Attackers who can observe raw traffic can hijack it (if it's the '90s) or redirect it (if it's 5 years ago, and in Brazil, and money is involved --- just to make it specific).

Look, we're locked in an Internet message board death struggle and neither of us are going to concede anything, so let me just finish with this tangent:

If you tried to sell an app to a Fortune 1000 company that defended against passive-only attackers but left logins open to active attackers, and they contracted out a 1 week 1 person web pen test to make sure your app was safe for peripheral customer data to go inside, you'd get dinged for this and you'd cut a dot release.

If, instead of cutting a dot release you explained why it was worth them moving ahead with a pilot that defended against passive attackers, you would Lose The Sale. Seen it happen.

I don't much care about your Hacker News password, but lots of you write applications, and I've seen some of the most unlikely (message boards, bug trackers, blogs---err, content managers) wind up in security audit hell. My advice, take it or leave it: don't bother with these Javascript hash schemes.

As should have been clear, I wasn't talking about apps with Fortune 1000 company customer data. I certainly did not suggest the mild javascript-hashing technique would be appropriate for such situations. (So, your 90+ word tangent hypothesizing that I might try to sell such a thing is... obdurate? A strawman? Unfair?)

And, you seriously think there are "no" passive-only attackers? No people happy to merely scan or log traffic, not actively hijacking TCP sessions, but looking for info to exploit later? I suggest both the guy in the wifi cafe running a sniffer, and the NSA hardware in AT&T's room 641A, count as "passive-only attackers". Of course the javascript-hashing technique is only helpful against the former.

It's not 1997 anymore. People don't hijack TCP sessions. Have you ever done that before? It's incredibly noisy.

If you can observe insecure traffic, you can redirect it. The victim's traffic is never going to hit ycombinator.com.

you are saying that if someone is encrypting the password using RSA in javascript and then using the hash to exchange the password between server/client, is volnerable because someone can interfere in the traffic and change the javascript served to the user, so that the password is sent in plaintext and therefore steal the password?

then why meebo and other sites practise this method without security problems?

The canned argument is: No known security problem does not mean no security problem.

That's not the argument here, though. The proposed solution --- and the one that Meebo uses, when you don't use their SSL login --- has a glaring security problem.

i wasn't proposing it, i asked if thats what you meant

i was implying, how come they didn't run into security problem when they are practising a non-safe method? why do they expose so many users to such danger without their knowledge?