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

[tptacek]

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.