Use multiple steps to exchange
General verification is to pass username and password. But how can I guarantee that the password is not leaked during the delivery? ? Some people may say that it is not finished with the password? But in fact, in addition to passwords are not leaked, there is also a need to ensure that there is no safety problem such as deception.
RSA is asymmetric encryption, which can no password from another third party. However, the third party can directly send the encrypted data to achieve the purpose of fraudulent servers.
Here is a solution I design, (absolutely original, but the principle is simple, not guaranteed that someone has used this.)
Now use triple des:
Step 1: Client, user Enter ClientUserName, ClientPassword client, send clientusername to the server side
Step 2: Server, after receiving clientusername, find DatabaseUsername if not found -> eXception -> Design a program telling customers that the user name is not found, end
Step 3: Server, get DatabasePassword, generate a string serverstr1, serverstr2, and store it (actually placed in session or elsewhere, but don't put it in the client, such as do not use ViewState)
Use DatabasePassword as Key to encrypt Serverstr1 to get serverstr1encrypted = tdes (Serverstr1, DatabasePassword)
Using Serverstr1 as Key, serverstr2 is encrypted, get serverstr2encrypted = tdes (Serverstr2, Serverstr1)
Pass Serverstr1enCrypted, Serverstr2encrypted to the client
Fourth Step: Client afford serverStr1Encrypted, serverStr2Encrypted ClientPassword used as Key, to decrypt serverStr1Encrypted obtain clientStr1 = ~ TDES (serverStr1Encrypted, clientPassword) with clientStr1 as Key, encrypted for serverStr2Encrypted be cut, to give clientStr2 = ~ TDES (serverStr1Encrypted, ClientPassword) If one of them is wrong, -> exception -> So tell the customer password is wrong, terminate
If the password is corresponding, Serverstr1 and ClientStr1 are corresponding. Serverstr2 and ClientSTR2 correspond. The purpose of this process is to use Password as Key, and then securely exchange the key STR2 between the two.
Use ClientStr2 as KEY to encrypt ClientPassword, get clientpasswordncrypted = tdes (ClientPassword, ClientStr2)
Step 5: Send ClientPasswordEncrypted to the server
Step 6: Server, get clientpasswordncrypted according to session status, test: clientpasswordncrypted == tdes (DatabasePassword, Serverstr2); if one of them is wrong, -> exception -> then tell customer password is wrong, terminate
If it is equal? Loginas (DatabaseUsername);
This method is not 100% security. The first is the problem of DES itself. This is not a scope of discussion. Then the most prominent problem is in the fifth step.
If the third party is terminated by the third party during the ClientPasswordEncrypted delivery process, then the third party will be recognized, and the clientPasswordEncrypted will pass the deception.
To prevent this, you need to make more session verification in terms of conversation in the sixth step. For example, it is determined by IP. (Physical factors are often better than digital factors)
Then more ways to do key exchange, (DESKEY is of course random, only on the session there)), the server adds ServerDesKey, as a transfer to the customer to the customer, it is SERVERDESKEYENCRYPTED = TDESKEYENCRYPTED = TDES (ServerDeskey, Serverstr1) Step 4, the client creates a clientDeskey as a server for information encryption using clientDeskeyencrypted = tdes (ClientDeskey, ClientStr1) and then handed over to the server at the same time in the fifth step and clientpasswordncrypted.
Then even if deception, the third party has no way to get two deskey, there is no way to send legal requests, and there is no way to decrypt the information.
this process. The core is still a session initial key clientstr1 = serverstr1
