This doesn't make any sense to me. If attacker can intercept connections I'd rather he get the hash than the plaintext password. At least then actual password is still not compromised, which is good, given how many people share passwords accross services. If he can tamper with connections, there's nothing that can be done anyway.

It would be very nice if there was a feature in web browser that allowed user to opt in to something like this:

When there's a password input on a website: 1] automatically take website's domain concatenate it to plaintext password 2] generate a secure hash from 1] 3] Derive some reasonably portable text password (20-30 characters) from 2] 4] Make it so that original web page never has access to user's plaintext password 5] Submit result of 3]

Downsides:

1] Stupid websites enforcing password rules other than length (can be worked around mostly transparently). 2] Extra stupid websites limiting password length. (requires user interaction and configurable exceptions for such websites) 3] Can't login with browsers that don't implement this.

This would be very nice for people who share passwords between services. Also would make web service data leaks less valuable to attackers. User would not depend on service password handling quality and/or operator's morality.

I use different passwords for each and every service. But many people can't be bothered or don't get the risks of password sharing, so it would be at least some help to them.

Exactly. That's the risk to mitigate. Here's scrypt for js using emscripten on actual scrypt C source... the site has to provide and adjust/migrate the three factors over time to ensure a sane amount of cpu/memory is used: https://github.com/tonyg/js-scrypt

For real-world, practicality's sake, the client-side of an app would contain the PBKDF or some AA code, as opposed to the traditional, slightly-riskier "let the server handle all of it"-approach... the server still has final say on authentication and authorization, just move some of it into client-side js. There's really not much impact on FE development considering most FEs and BEs are codeveloped these days anyhow.

Btw, for web devs Two-factor auth is cheap and easy to do, Google Authenticator OTP has open source libs and requires no calls to Google to work.

You're wrong because it's a strawman since if an attacker can intercept the hash they could as easily intercept the plaintext in your traditional server-side architecture. The attacker cannot replay a TLS unless there is a problem with it, there have been many issues in TLS stacks, but it's the most widely deployed.

Furthermore, using plaintext any further from the owner or exposed longer than is necessary is inherently less secure because your breach of https would also compromise users' passwords.

> Use https. And don't do client-side hashing, it's no improvement.

Well, it's an improvement if your users are reusing their passwords. Then multiple different sites will have different hashes sent.

But that's all besides the point, we should've been using zero knowledge proofs for authentication since the beginning.

With HTTPS, multiple different sites will have different "hashes" sent anyway, so no, it's not an improvement over just good ol' HTTPS.

Well, sure. But then you have to worry about how well the website is storing your passwords. Meh, password managers are the way to go to be honest.

Most websites with any sense dont store actual passwords, they usually store salted PBKDF hashed that are compared in constant time.