Hacker News Reader

Comment by jsjenkins168 | Hacker News Reader

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

View on HN

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.

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.

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.

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.

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

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.

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.

I can't win that argument; it's semantic. Just remember that the majority of the decision you're talking about belongs not you but your users. Don't offer a false sense of security.

Reply on news.ycombinator.com