Earlier quoted context omitted.
> Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable. This is not safe! Now an attacker just needs to intercept the hashed password and replay that, and he gets to login without knowing what the password is. Use h…
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…
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.