> If client uses deterministic salt, then whatever you send over the wire is equivalent to password and constant for every authentication. If server sends random challenge which is then hashed by client together with something derived from users password then whatever value that is stored on server in order to check validity of the response is sufficient to fake the response (and also essentially equivalent to plaintext password as it has to be derived from it in some deterministic manner independent of the random salt/challenge)
You seem to misunderstand the purpose of what I am proposing. I am not proposing this scheme as an alternative to what's proposed in the blogpost.
I am proposing this procedure as an extra protection step for password reuse. If you were to run an exploit on the server that reads its memory contents, you may find a user "Admin" that uses the password "FavoriteFood-DateOfBirth".
If you sent the original version of that password, then such an attacker will find real-world information about you. That information can be used to exploit your identity on other websites. If the password is hashed, then that information doesn't get leaked. Sure, you can fake your authentication to this server, but you have not gained real-world information about your target.
Without salt, the attacker can fake the authentication on every service where that password gets reused. But with salt, every server sees a completely different password on their end. Essentially, your hashed password with salt has become your new password in the server's eyes.
> : for security features like this to be truly secure the user has to be sure that he is interacting with the native browser/OS UI and not with something that can be intercepted by JS
Yes, you were one step further than me on this front. I do agree that communicating this to the user is non-trivial.
