That's not true if you ask the client to hash both the password and a one-time token you just send.
Knowing both the password/key (which was send during registration) and the token, you can calculate the hash. Otherwise you can't. Password/key is never transmitted.
You can also use asymmetric encryption. I always cringe with amateur devs sending plaintext.
It does. You can do the same with with the salted hash of the password and not the password the user entered. It's still worse than real authentication protocols where you don't store the shared secret at all, but better than those diy schemes described earlier.
Also you can't get away from sending the shared secret during registration. Even with asymmetric cryptography you have to rely on the TLS to make sure you exchange the real untampered public keys.
