3👍
It is standard practice to send "plaintext" passwords over HTTPS. The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.
Encrypting the password before sending it in HTTPS doesn’t accomplish much: if the attacker got their hands on the encrypted password they could simply use it as if it were the actual password, the server wouldn’t know the difference. The only advantage it would provide is protecting users that use the same password for multiple sites, but it wouldn’t make your site any safer.
0👍
As indicated, generally the security layer of HTTPS is trusted.
Technically speaking, it is possible to split the password hashing in two. You can simply perform one number of iterations on the client (browser) and the remaining on the server. You want to perform at least one iteration on the server as you would otherwise get the value that the clients send to be stored in the database: i.e. getting a copy of the values in the database would directly leak all login credentials… not good.
So this would likely mean two separate bcrypt hashes to be performed if you want to keep using that algorithm. You can reuse the same salt I suppose, but storing a separate one should always be preferred. Of course, performing bcrypt at the client side will spike the CPU locally, which may hamper performance, spin up fans etc., and that’s assuming the JS will run OK.
Finally, if the TLS is completely broken then somebody can simply inject a script that will leak the password. So hashing it locally will only increase security by a relatively small margin. It could still be somewhat useful against future decryption attempts, but in the end you’ll have to rely on TLS anyways. So the answer to "How do you guys solve this?" is generally: we don’t. It might make slightly more sense in a mobile app or full size application.
Interesting to know, there have been submissions such as Catena and Makwa to the password hashing competition that explicitly allow the client to perform part of the hashing. Generally this is more performed for offloading the password hashing to other systems and alleviate the use of valuable server resources.