Plain text password over HTTPS

It is safe. That's how the entire web works. All passwords in forms are always sent in plain text, so its up to HTTPS to secure it.

You still need to make sure you send it via POST request, not GET. If you send it via GET request, it could be saved in plaintext in the user's browser history logs or the webserver's access logs.

If HTTP is disabled, and you only use HTTPS, then you're not really transmitting the password as plain text anyway.

Let’s make some notes to previous answers.

First, it’s probably not the best idea to use hash algorithms client side because if your password is salted on the server side, you won’t be able to compare hashes (at least not if you don’t store the client hash in the database in one of the hashing layers from the password, which is the same or worse). And you don’t want to implement the hashing algorithm used by the database on the client side, it would be silly.

Second, trading off cryptographic keys aren’t ideal either. The MITM could theoretically (considering he has a root cert installed on the client) change the cryptographic keys, and change with his own keys:

Example from an original connection (not considering TLS) from a theoretical server that exchanges keys:

Client request public keys > server holds the private keys, generate public keys to client > server sends public keys to client

Now, in a theoretical MITM atrack:

Client request public keys > MITM generates fake private keys > Server holds the private keys, generate public keys to client > MITM receives the public keys from the original server, now, we’re free to send our fake public keys to the client, and whenever a request comes from the client, we will decrypt the client data with the fake keys, change the payload (or read it) and encrypt with the original public keys > MITM sends fake public keys to client.

That’s the point of having trusted CA certificate in TLS, and that’s how you receive a message from the browser warning if the certificate isn’t valid.

In response to the OP: in my humble opinion you can’t do that, because sooner or later, someone will want to attack a user from your service and will try to break your protocol.

What you can do, however, is to implement 2FA to prevent people from ever trying to login with the same password. Beaware of replay attacks, though.

I’m not great with cryptography, please correct me if I’m wrong.

The other posters are correct. Now that you're using SSL to encrypt the transmission of the password, make sure you're hashing it with a good algorithm and salt so it's protected when it's at rest, too...

@CodeDog example has issues..

Yes, I can believe that users will log into a caffeteria box. If you are capturing logs from a corporate caffeteria, then you are the security breach. Corporate caffeterias boxes should be setup disabled, e.g. no terms, no loggers, no remote access, etc. In order to prevent you, the inside hacker.

The example is a good one of computer access security, and not really related to network security. It is provided as justification for client side hashing, but if you have computer access you could just use a keystroke logger and bypass that. The client side hash is again irrelevant. The example by @CodeDog is a computer access hack and requires techniques different from network layer hacks.

Also, a public computer hack is protected by crippling the system from threats, as mentioned above. e.g. use a chromebook for a public caffeteria computer. But that is bypassed by a physical hack. During off hours, go to the caffeteria and setup a secret camera to record keyboard presses by users. Then it doesnt matter if the caffeteria computer is crippled, OR what type of encryption is used.

physical layer -> computer layer -> client layer -> network layer -> server layer

For networking, doesnt matter if you hash on client side because the https/ssl layer will encrypt the plain passwd. So as others mention the client hashing is redundant if the TLS is secure.