Maugrim_The_Reaper wrote:The javascript is sourced on the host server (whether genuine or not) so yes, a phish or other could remove that layer, induce a user to enter a clear password, and submit it to the evil people on the other side of the connection. Or worse.
The concept that ralfhauser is putting forward is that of a browser with a trustable C/R mechanism. Several problems with that idea:
1. Most users don't have it, and won't install it, even if you ask.
2. It doesn't buy you much additional security over a correctly implemented js C/R.
If your js C/R accepts a (reasonably strong/unique) salt, and sends only the salted, hashed password, then there is little additional benefit to a system like pwsafe.
For there to be a risk to protect against, you have to have a scenario where the phisher took control of the browser or PC of the user. The only difference then between pwsafe and js is how difficult it is for the attacker to subvert/replace that layer.
A salted, hashed password gives the attacker nothing. Even if they know the hash method, AND the salt (they created it, right?) they still don't get the original password.
If they are subverting the code to get the cleartext password, they can do the same against pwsafe.
The truth is, as you say Maugrim, that C/R is simply a layer of defense. Its not a perfect defense, and its not meant to be. Ideally, you should use C/R on top of SSL, with client certs, and more.
But realistically, for most sites, even C/R is a bit of overkill. We're not talking about protecting the pentagon's codes - we're talking about Bob's Website, which shouldn't be sloppy, but doesn't need to be Fort Knox online either.
Security is a process that reduces risk. C/R (even via javascript) is a solid improvement over the null state. Could pwsafe take it further? Possibly, but SSL would be a better investment of time and effort.