Obligatory post I make on these stories: Use PwdHash for Firefox and Chrome. It's very low overhead and provides and extra layer of protection from lazy programmers.
That only tackles the master password for every site issue. It does not solve the password being plaintext.
For example, Facebook has a central ID and if they don't protect the password that gets exposed, someone could use the password to withdraw money from another section of the website.
Not quite. At the moment it's virtual currency [0]. My point was that security holes increase as service increases in complexity. Especially when it's used for everything and becomes a hard lesson in SPoF for users, like the money example.
PwdHash looks great and it would be nicer if it was implemented by all browsers. To take the idea further, what if the HTML5 standard for input type=password automatically did the hashing before forms are submitted? On any form submission, browsers would hash like PwdHash by using the current domain. There would also be no need to use a prefix like PwdHash. Those are some quick thoughts and I think there's better ideas that can be implemented, that don't require work for consumers. Won't protect against things like weak passwords, but even a little contributes to security.
I use PasswordMaker which has support for pretty much every browser and uses the current url for hashing (and you can always override the default salt). http://passwordmaker.org/
Holy cow. This thing is even better than PwdHash (ability to avoid special chars in particular, and multiple platforms supported, and it's actually being maintained). Thanks!
> On any form submission, browsers would hash like PwdHash by using the current domain.
Nitpick: works great until you move domains, or try to log in from another subdomain, or use a redirect in your /etc/hosts file, etc., etc.
Assuming that the submitted hash would (should!) be salted and hashed again server-side anyway, simply running it through bcrypt would be enough, I think.
An optional attribute could be added, too: <input type="password" salt="sosasta" />. If we wanted to go further, the salt could be a randomly generated nonce that would be submitted as another field; POST['password'] = 'whatever', POST['password_salt'] = 'sosasta'
I don't think a nonce would work, because the server wouldn't be able to verify whether the hashed value you sent was correct or not. The whole point is to never send your 'real' pwd to the site, because they're going to do something idiotic like store it in plaintext, and then you have to change it everywhere.
For example, Facebook has a central ID and if they don't protect the password that gets exposed, someone could use the password to withdraw money from another section of the website.