[loonyphoenix]

That relies on every website implementing this solution, and I don't think such coordination is possible.

Also I don't see the advantage over just server-side hashing. Client-side hashing (without a password manager) is public, so the salt the site uses is known.

[tomglynch]

Well any website serious about security - yes. But if a single website decides to do it it would work fine. It would be quite easy to just add a js file with this. For example this one for the Stanford JS Crypto Library: https://github.com/bitwiseshiftleft/sjcl/blob/master/core/sh...

We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.

[loonyphoenix]

How would protecting a single website help? If the password is shared among different sites, and one of the sites turns out to be malicious, I'll be able to access your single website just fine by typing the sniffed password into your textbox, whereupon it can use however much hashing and encryption as it wants and it won't help.

[tomglynch]

Ah I see what you're saying. You're right, in the interim period before everyone changes to client side hashing that is an issue. Though there's no loss to implementing it, but it's just not as beneficial until more sites have it.

For example: If there is no client side hashing: a user uses the same password for n websites. If one of the n websites gets hacked, an attacker can login to all n sites.

If one on site you have client side hashing: a user uses the same password for n websites. If one of the n-1 websites gets hacked, an attacker can login to all n sites. If the client side hashed website is hacked, the attacker can only login to 1 site.

Once each site has a unique salt, then we're secure.

Another issue is how can a website migrate over to client side hashing? I don't think there's an elegant way to do this.

[xtomus]

It can be a web platform API.

[tomglynch]

Hahaha, genius! Where we send the password in plaintext and return a hashed version! /s