Hello friends on the login screen, we encrypt your username and password on the client side with crypto.js or on the server side with md5 and save it to the database. Ok but 2 questions stuck in my mind
1.The only purpose of encryption on the client side is so that if a hacker who scans the wifi with the snifer program captures the password, he cannot log in. However, for example, my password is 1234 and when this is encrypted with crpyto.js, the output of this is If the hacker enters the password xeeXX3^F again, it will be 1234 again on the server side, then what is the point of encryption?
2.When encryption is done on the server side, we save it to the database again encrypted.And if a hacker writes the password created with md5 in the database to the login section again, will the output on the server side not be 1234 again? Since the whole world does not make mistakes, where do I think wrong thanks
I did encryption but I don't understand the logic
When a password is sent over the network, encrypting it (with a secure method) prevents an attacker from "sniffing" the password and then logging in with that password.
Generally, "secure method" means that you are encrypting with an algorithm suitable to the task (key elements being the size of the information being encrypted, the length of time it needs to remain secure, and the effort that you need to put in on either end to perform the encryption). In practice, the best method is to use Transport Layer Security (TLS) which is the modern method of implementing the HTTPS protocol.
In the example you give, you don't say whether CryptoJS is the only method used for securing the transfer, or whether HTTPS is also used. Without reading the source code of your browser-side login routine, I can't tell if you are protecting against the failure modes of this method. However, if you use CryptoJS to encrypt just the username and password, without any padding or unique values, for transmission to the server; and if you use a key that does not change per-request then if the attacker captures the encrypted password they could replay the encrypted password to your server without knowing the original password. This would break your authentication.
So I would answer to your question 1 that it may not be providing security for your authentication to use CryptoJS, and if you are using HTTPS with CryptoJS then it could be no better than using HTTPS by itself.
I should start by saying the MD5 is not an encryption algorithm. It is a hashing algorithm, which is distinguished from an encryption algorithm by there being no intended way of returning from the output value (the stored hash) to the input value (the password). So addressing the specific question, if the attacker provides the MD5 hash of the valid password to the server, then the output of the MD5 hash then performed by the server will not be the password, but the output of the MD5 function applied twice to the password. With some forms of encryption algorithm, applying the encryption function twice will return the original value, but not so with a hashing algorithm.
The short answer to whether this is good enough for storing a password is "not really". MD5 was a common method for this for a long time, but it was never very secure if what is referred to as a "salt" was not used. A "salt" is a random per-user value that is known to the server and combined with the provided password. This prevents identification of shared passwords between users of the same or different systems, and therefore a potential attack from a list of hashed passwords. When a salt is added, it is more secure, but for the last ten years or so MD5 has been considered below the threshold for good security since it is relatively efficient to perform a hash with it on a modern computer and it has several cryptographic weaknesses.
It is now considered better to use a purpose-built hashing algorithm for password storage, with the most common being PBKDF2.