If you trust the site to deploy correct JavaScript to do this, then that's the same level of trust that they implemented password salting and hashing server side. You don't gain any robustness by moving this to JavaScript.
Your scheme is just a weak salting technique. You'd be better off with just using a longer salt and hash function.
I can trust the site to deploy the correct javascript more than I can trust it not to steal passwords because
- That is auditable - it is impossible for a malicious site to do so without risking being caught.
- The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
Hardly. Minimization and obfuscation is trivial, and you can ensure the output is always different in order to defeat auditing. Not great for caching obviously, but 'auditability' is not achievable if the server is determined to fool you.
> - The HTML/JS can be served from static cloud storage that is far less likely to be hacked than the server running a DB verifying passwords.
Password are simply not where you want to leverage your security. If you can find a document example of a real threat that this approach would have mitigated, then I'll take it seriously.