[jsjenkins168]

As was pointed out by tptacek, this approach is not secure because the javascript can be rewritten in transit. Also consider that javascript-based hashing will be extremely slow and could interfere with the user experience if the browser bogs down. And IE may show an error that performance is slow on your site.

There just is no way around it, the only way to be secure is use SSL to share secrets when you register. From then on you can just transmit an authenticator (stored in a secure cookie) comprised of an expiration timestamp, any identifying user data (like userID), and a non-malleable MAC digest of the expiration and userID. Doesn't protect against replay but it helps to enforce a short expiration for the authenticator. With this approach you'll only need to use SSL for the initial login.

This is the best explanation of web authentication I've encountered on the net [PDF]:

http://prisms.cs.umass.edu/~kevinfu/papers/webauth_tr.pdf

[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.