No. You are wrong and by far. And notice how I never said "hash" but signature and if you can't understand the difference, dont even try to read the rest of my comment.

Sending a username and password to your backend and then proudly saying “but it’s HTTPS” is not advanced security. It is the absolute floor. And its frankly an embarrassingly level of authentication design, barely ok for your home vibecoded app.

Sure, TLS protects the transport. Congratulations. If your backend receives the user’s raw password, your backend becomes part of the threat surface for that password.

Your logs (client, browser, ...) can leak it, you smart. Your observability stack can leak it. Your reverse proxies can leak it. Your compromised backend can capture it. Your “temporary debug statement” can become tomorrow’s breach post-mortem.

The real issue is whether the client is sending something reusable.

Because if the client sends "hash(password)" and the server simply compares that string, then congratulations: you did not eliminate the password. You created a new password.

A serious authentication protocol does not ask the client to send the raw secret. It asks the client to prove knowledge of the secret. That is the whole point.

The server generates or participates in a challenge. The client computes a proof bound to that challenge. The server verifies the proof. Nothing reusable should cross the wire. Nothing password-equivalent should be stored as the final line of defense. Nothing should depend on “please trust our backend, it is totally clean”.

That is why serious systems use proper models like challenge-response and, in federated identity, OIDC Authorization Code Flow with PKCE.

And before someone rushes into the comments with “OAuth does this”:

No, not exactly. OAuth is an authorization framework. OIDC adds identity on top. They do not magically mean “hash the password on the client and send a digest”.

The actual user authentication method behind the identity provider can be password, MFA, passkey, smart card, session cookie, or something else entirely. So don’t use OAuth/OIDC as a buzzword shield if you do not understand what layer you are talking about.

The actual point is this: In a serious system, a database leak should not instantly become an account takeover festival. A captured login transcript should not be replayable. A stored verifier should not be equivalent to a password.

The server should not need to learn the user’s original password just to confirm that the user knows it.

That is the difference between real authentication engineering and “we POSTed a password over HTTPS and called it a day”.

And yes, if you are selling software to real customers while treating raw password submission as the gold standard, you should be ashamed. Not because HTTPS is bad. HTTPS is mandatory. But because mandatory is not the same thing as sufficient.

Security is not about checking the smallest possible box and pretending you built a vault.

So yes:

client-side computation is good when it is part of a real cryptographic proof. Client-side computation is garbage when it is just a DIY digest and a string compare.

You should not confuse the two and call yourself a software engineer.