The overall situation is rather complicated. The shortest answer I can give is that it's a solvable problem in principle, but not really solved in practice. I'll give a more complete summary in "good news - bad news" format:
Good news: TLS uses server-side certificates to insure that your encrypted connection is going to the server you intended to talk to, and not being intercepted by some impostor (such as a MiTM).
Bad news: TLS only works if you use it. TLS connections aren't always the default, and things like sslstrip can (mostly) prevent the usual ways of upgrading connections to TLS.
Good news: TLS is gradually becoming the default, HSTS can lock in TLS after first use, and in many situations (client-side apps, for example) the client can know in advance to use TLS.
Bad news: Our certificate infrastructure (certificate authorities, etc) is not entirely trustworthy, and bad/fraudulent certificates do get issued.
Good news: We're starting to use things like certificate transparency and certificate pinning to provide additional checks.
Bad news: Some organizations use TLS-intercepting proxies for network security. These use their own certificates, and are therefore completely detectable by the client (and will be rejected as insecure by default). However, in these situations, the client is effectively forced to change its policy, and trust the proxy's certificates if they want access to the Internet. For a while Kazakhstan was doing this country-wide! Unfortunately, these proxies can watch the entire (unencrypted) client authentication process.
Good news: There are authentication methods that never send the password, even in encrypted form. The most basic of these use a hash of the password to authenticate, but that means the hash itself is sufficient to authenticate, making pass-the-hash attacks possible. There are better methods that don't expose the client's credentials to even a TLS-intercepting proxy, such as client-side certificates and password-authenticated key exchange ("PAKE") protocols (most notably, the Secure Remote Password, or SRP protocol).
Bad news: client-side certificates are unweildy, since they require the user to carry around a certificate file rather than just remember a password (not that remembering passwords is easy -- you can/should use a password manager, but they generally don't support certificates).
Mind you, if you're writing a mobile app (or other situation where you're writing the client), you aren't limited to what any browser supports and can go ahead and use SRP or something similar with a full, secure, native client implementation.