Some web security protection products, in order to prevent account passwords from being attacked and cracked by automated tools, adopt a technical method: encrypt account passwords, even cookies, on web pages, and then transmit them. It is hoped that this encrypted transmission can achieve the purpose of security protection and anti-cracking. Does this really work? Let's look at it step by step:
Take the following piece of transmission data as an example:
What is the effect of protection?
POST /login/ HTTP/1.1
Host: 192.168.80.131
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: [http://192.168.80.131/login/?next=/](http://192.168.80.131/login/?next=/)
X-Requested-With: XMLHttpRequest
Content-Length: 443
Content-Type: multipart/form-data;
boundary=
---------------------------146043902153
Cookie: csrftoken=XJeOhq0dkSPVb3zBWhArYLNQxpqkm
Connection: close
-----------------------------146043902153
Content-Disposition: form-data; name="logname"
admin
-----------------------------146043902153
Content-Disposition: form-data; name="logpass"
14e1b600b1fd579f47433b88e8d85291
------ -----------------------146043902153
Content-Disposition: form-data; name="csrfmiddlewaretoken"
y7BblF2tcCBSQ6SZHLltrI1ocnWVQ0KcXVgo
------------ -----------------146043902153--
It is obvious to see that the password part has been encrypted.
What will the attacker do?
If this kind of protected situation is encountered, what would an attacker generally do?
1. The general idea:
Ready to crack the dictionary -> look up the website user name password encryption method -> use a scripting language (such as JS) to simulate the front-end encryption method, use the cracking dictionary -> use the replay tool to load the encrypted blasting dictionary to explode Force cracking.
2. Great God Idea:
Ready to crack the dictionary -> look up the website username and password encryption method -> request the plaintext username and password to NodeJs -> NodeJs directly call the JavaScript encryption method to encrypt -> NodeJs sends the encrypted username and password to the need to blast Website -> NodeJs judges whether the username and password are correct according to the website response -> Use the replay tool to blast in a loop.
Actual combat drill:
On the login page of a certain website, the password is encrypted and transmitted during the user's login process. 
If the login is successful, the return errorcode is equal to 0: 
If the login fails, the return errorcode is equal to -1.
use tools
Burpsuit, NodeJs
burpsuit is used for replay, nodejs is used to write automatic attack scripts.
Actual combat process
1: Find the website password encryption method
a) View the source code of the login page. It 
can be seen that form.append("logpass",hex_md5(hex_md5($("#logpass").val()))); hex_md5() is called twice to encrypt the password entered by the user.
b) Find the location where the hex_md5() encryption method is defined.
2: NodeJs calls the JavaScript encryption method to encrypt
a) Save the md5.js file locally and use export to expose the encryption method. 
b) Create a NodeJs server and receive http GET requests.
Create a server.js file and write the following code into the file: 
c) Reference md5.js to encrypt the user password received by nodejs.
Add the encryption code to server.js. The Server.js code is as follows:
3: Use the replay tool to blast in a loop
a) Open the nodejs server
node server.js
b) Test 
the blastability Check the website return information in nodejs: 
c) Use burpsuit to replay the node.js server.
The password was successfully cracked! :
in conclusion:
The encrypted password is still cracked, indicating that the encrypted account password is not automatically cracked, which is insecure and a failed theory. Although many security vendors advertise that the transmission content can be encrypted, in fact it is all useless and in vain, because the path is wrong at the beginning, and the encryption is useless no matter how good it is.
The correct idea of preventing automatic cracking:
Like the above operation, what if it is not to encrypt the content of the password, but to encrypt the password field itself? That way, there is no account password to verify! In that way, a real anti-automated cracking attack is achieved.