[DaniFong]

Depending on who you are, you could guard against javascript being rewritten by a man in the middle attack by running, say, a greasemonkey script that figures out when a password should be sent and hashing with the server domain automagically, so long as you can cache it locally. In this way, admins could secure clients against having their passwords stolen without any effort on the part of web-app writers, or users. Even a browser, say, Firefox, could do some version of this.

Really, digest authentication solves the same problem, but hardly anyone uses it.

[tptacek]

I know you're just trying to add a layer here, but if you think this through, you'll probably see that GreaseMonkey does not win against content-controlled Javascript for its own site. Firefox has had a hard enough time just keeping content-controlled Javascript from breaking into Chrome.

As a simple example, note the fact that the "when the password should be sent" signal originates from content-controlled JS, which controls the DOM. Note also that with same-origin out of the picture, the content-controlled JS can choose to send the password whenever it wants.

[DaniFong]

Sure, it's not meant to be foolproof. I only wanted sometime to secure the login for the large number of sites taking passwords with plaintext. Right now it's completely a statistics game -- you can just stand outside someone's wireless network capturing packets. If it's insecure or WEP, you'll be able to recover the key, then grepping through with password=_ will eventually give you a password to use on their favorite sites.

I do think security is a matter of degree. And currently authentication is but a few removed from wide open.

[tptacek]

This is why app developers should be using SSL. I have no smart-assed responses to an HTTPS login screen. No ad hoc hashing schemes required.

[DaniFong]

By the same logic, crackers shouldn't attack anything. But they do.

[tptacek]

I'm not sure I see how that follows.

But to reify this a bit, do a little Google research on what the banking industry is dealing with regarding multifactor authentication. Nothing they are trying is working, and they're doing considerably more than Javascript hashing. The schemes being discussed here are being attacked, successfully.

[DaniFong]

Not every app developer who could use SSL does, which can give away passwords shared with SSL sites.

By the same token, some hackers capable of cracking do so, though they, in some sense of the word, really shouldn't.

We're thinking about security from two different standpoints. If I lock my door, but my glass window has no bars, I'll still say it's more secure than a house with a door open. The issue, for me, is less that someone can, but whether someone will. If I make it harder for someone to mess with me, maybe they won't.