Where should you start encrypting your password?

Question

PHP

When registering/authorizing, the user enters a password. This password is then sent to the server for verification/saving. How would it be wiser: to encrypt the password before sending it to the server, or already there on the server to accept it "as is" and then md5'it (for example)?

Answer 1

https is smarter.

Answer 2

Naturally, encrypt on the server + https. Otherwise, the attacker will calmly look at the encryption algorithm in JS.

Answer 3

As Vladimir Martyanov already told you , https is better. If absolutely nothing, I will explain why it is impossible neither so nor so.
Suppose we encrypt on the server:

_______                 ______             _________
  |     |                /      \            |       |
  |     |               /  #  #  \           | # # # |
  |_____|     ------->  |  ____  |  -------> | # # # |
  /     \    password:  \ /    \ /           | # # # |
 /_______\ "mypassword"  \______/            |_______|
   Client               Ugly hacker           Server

If on the client:

______                _________            ______
 /      \               |       |           /      \
/  #  #  \              | # # # |          /  #  #  \
|  ____  |   ------->   | # # # | -------> |        |
\ /    \ /   password:  | # # # |  login   \ \____/ /
 \______/    "hismd5"   |_______| success!  \______/
Ugly hacker              Server          Smiling hacker

Answer 4

I wonder why *CHAP technologies are not used in the web. This imposes a restriction on the server that it will store passwords with reversible encryption, but at the same time protects against wiretapping.
Even Https is not a panacea - remember avast, which replaces the root certificate of the protected system, if an antivirus can do this, then any trojan can compromise https on the client.
I would very much like to see an implementation in which the password was encrypted on the client in one way, transmitted to the server, encrypted there with the server salt, and the hash of this password would be stored in the database. During authorization, the client makes the first hash, salts it with the salt received from the server, and transfers it to the server. the server salts the password in the database with the second salt, and the received authorization hash with the first salt. Compares hashes. With this approach, the open password will be only in html form and there is a restriction on the choice of hash functions. but with a rather complex encryption algorithm on the server, it becomes more difficult to guess the password and reuse the hash.
It remains to add to this a method that allows you not to store the password in the input field as you type ...