An attacker that would have the ability to impersonate the server could precompute a rainbow table for a given salt, and send that salt to the client.

OTOH, without client-side prehashing, an attacker that has the ability to impersonate the server doesn't have to precompute anything in order to collect all passwords.

>An attacker who has visibility into the client that has the salt can already see the plaintext password.

There is no way for the server to distinguish a legitimate user trying to login from an attacker trying to hack someone. So if the salt is sent to a legitimate client, the salt will also be sent to attackers.

I'm not sure if sending the salt to attackers is really a vulnerability though.

I'm still wondering how to deal with password changes in that scheme. If you change the salt, you reveal the existence of that account and the fact that the password changed. But keeping the salt the same seems unsafe as well...

Since getting the salt must be possible by supplying only username, one security disadvantage of such scheme is that by getting the salt of the target the attacker can precompute password guesses and store them. When the password verifier database leaks, the attacker then can more quickly verify guesses. This is a really tiny advantage and may even be more expensive than non-precomputed attack due to storage, so it doesn't matter in the real world.

Another disadvantage is that if changing password also changes salt, by requesting salt over the period of time, the attacker can learn when the password was changed.