Website Security Login Web Application Security Login Password anti-Interception

Statement: I am not very familiar with this part. The solution proposed here is just an idea of my younger brother. I hope experts from all parties can help me identify the problem.

Difficulties:

In normal times, web applications and websites generally have the user login function. Therefore, the logon password must be involved. How can we ensure that the user's password will not be obtained by third-party attackers?

There must be more ways to break the law. For advanced users, they can directly Mount Trojans and client Trojans. However, if we do not consider this much, we assume that both the webpage and client are secure. How can we prevent interception on the network?

Original method:

Generally, if it is an internal enterprise application and there is no security requirement, it will be ignored directly. Send the email using the account and password ~~ What's wrong ~~

Security Method 1:

Before post, use des to encrypt the password and decrypt it on the server.

Problem:Once the key is intercepted, it is very likely that the password is decrypted ~~~

Security Method 2:

The MD5 Hash Value of the password is stored in the data inventory. MD5 hash is first performed before each post. In this way, the password cannot be decrypted.

Problem:Okay, I won't decrypt your password. I directly replay the attack. If you send a message to the server, I will send a message to the server. You can also impersonate your login.

Security Method 3 (for now I think it is safer):

1. the MD5 Hash Value of the password is stored in the data Inventory (preventing the user from directly starting with the database)

2. Each time the login page is opened, a random RSA public key is assigned to the user (hundreds of key pairs can be created to ensure efficiency)

3. Use the public key to encrypt the post password. (Ciphertext cannot be cracked even if the public key is intercepted. It is proved mathematical ~~~ Hey. At the same time, even if the attacker replays the attack, the attacker sends the same ciphertext to the server. Because the public key is different each time, the attacker still cannot log on to the server)

4. Because there are only several hundred keys, it may happen that the same public key is encountered to prevent unauthorized users from constantly trying. In this case, you need to add 5 logon failures to the account for 30 minutes ~~~ (Hey, let's see how you try it. Of course, if you can ensure that each key is different, you can skip it here)

5. The server obtains the ciphertext of the password encrypted by the public key, decrypts it with the private key, and hashes it to match the MD5 value of the Database Password ~~ Completed ·~

Some available resources:

Http://www.jcryption.org/

Http://www.michalfranc.com/articles/jcryption.html

How can this problem be solved ~~

Refer to the principle of HTTPS :( http://zhenggm.iteye.com/blog/558785)

The sequence of HTTPS communication is as follows:


Figure 3 HTTPS communication sequence