[jc123]

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.

[rapind]

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/

[anonymous246]

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!

[pavel_lishin]

> 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'

[e28eta]

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.