Then there is the UX problem where mechanism like that would have to be implemented on the browser level (and in fact it is as Authorization: digest is mostly what you are proposing) which according to some leads to “ugly and confusing” UI.
I don't understand what you mean. Just in case I didn't make myself clear, I don't mean substituting the hashing on the server, I mean adding it on the client.
> Also it would require additional roundtrip to server in order to get the stored salt.
It could be salted with some constant/domain name.
> Then there is the UX problem where mechanism like that would have to be implemented on the browser level
What I am saying could perfectly be done with javascript, although I don't see why browsers could not integrate it too.
> which according to some leads to “ugly and confusing” UI.
I am completely lost, I am not sure if you understood me but I don't understand what you mean. Can you explain yourself further or provide a resource that explains this UX problem you're talking about?
There is no technical reason why this could not be implemented in pure JS (and there is lot of things that do something like that with varying complexity and security properties). But there is the question of exactly what is the threat model where the server is trusted to provide implementation of code that defends against compromise of that exact same server.
And as for the UX/UI issue of browser-based security: 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 (or some other untrusted code). This is the reason why various parts of browser UI cannot be hidden, why legitimate permission popups overlap browser toolbar and the idea behind Ctrl-Alt-Del in Windows NT. Such UI by design cannot look as part of your website/application which both confuses even technical users and annoys marketing people because of added friction.
Also what didn't help adoption of any kind of more secure authentication for public facing websites is that in IE the resulting UI was ugly, inconvenient and in some cases downright broken (eg. dialog box used to confirm that you really wanted to use certificate from PKCS#11 token not only didn't say what for, it didn't say anything except “Error! Yes/No”).
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.
It would help in the case of reused passwords, which is still rampant in my experience.
