Secure login password is not secured in a more robust manner under the HTTP protocol

Speaking of how user login under HTTP protocol guarantees password security:
Small white Maybe the first idea is that when a user enters a password to sign in on the login page, the foreground page encrypts the password entered by the user, and then sends the encrypted password as an HTTP request parameter over the network to the server.
This does not guarantee the user's account security, because a little bit of programming knowledge can be sent through the HTTP request you know your password, small white and said, I password encryption, it got the password is encrypted, it does not know my original password it is unable to log on from the login page.

The original text is discussed with the author: http://www.cnblogs.com/intsmaze/p/6009648.html

Sina Weibo: Intsmaze Liu Yangyang

But little white ah, you have not thought, sometimes I just know your encrypted after the plaintext is enough, I can forge the HTTP request, the plaintext in the request parameters, the same can be logged into the system.
There's something to be said, white: I can add salt to the code. OK, let's see what the salt is, add salt simple is the program to the user set up the original password after the addition of random number to enhance the complexity of the user password, and then encrypt the combination of the password to store, the user every login, the front end of the user input password encrypted transmission to the backend, Then the backend obtains the user's account to the database to find the user's salt, and then the plaintext combination sent together with the password in the database after the comparison to determine whether it is in line with the user. But Ah, great white, you see, to do this, and to control other people through your HTTP request to obtain clear text, after obtaining, they still swagger use your identity to log on to the system to operate.
OK, big White let me talk to you about the true meaning of salt: salt is not meant to ensure the security of the network transmission, but to prevent the database is invaded, because the original password is too simple to be analyzed, and then know the password. MD5 the password directly after processing, the reverse decryption is really difficult, but still can find flaws such as: two people or more than one person's password is the same, through the MD5 encryption after saving will get the same result. Break one can break a piece of code. If the user can view the database, then he can observe his password and other people's password encryption results are the same, then, others use and their own is the same password, so that you can use the identity of others to log in. So does our previous encryption method invalidate this behavior? In fact, as long as a little confusion can be prevented, which in the encryption term called "Add salt." In particular, in the original material (user-defined password) to add other components (usually the user's own and constant factors), in order to increase the complexity of the system. When the salt is combined with the user's password, the digest will be able to get a more hidden digest value.
     small Black said: You said these I understand, I will tell you the final solution: After the user entered the account, The background Ajax sends the user's account to the server, this time the server generates a random number verification code for the account, responds to the front-end login page.
     when a user enters a password, the front-end page encrypts the password entered by the user. The encrypted plaintext is then combined with the verification code returned by the server to encrypt it again. Then send this information to the server, the server session to save this account of the verification code, the server from the database to obtain the user's password and verification code combination of re-encryption and the front end of the clear text to compare and judge.
OK, then let's analyze why it's safe, because the CAPTCHA is a one-time, so you can't do replay attacks after the network layer gets this request. Because the captcha is incorrect. And when you get a new verification code, but you do not know the composition before the content [MD5 (MD5 (password) + user QQ number)] is what, so you can not resend this request to achieve the purpose of landing. 32-bit MD5 + 4-bit Verification code total 36-bit string, you go crack it. I guess you can't break it if you hang up. As for the service side of the check, as long as the recorded MD5 value (instead of the recorded plaintext), the same operation, the result is the same as the submitted, that is, the password is correct. The content of the verification code is issued by the server, and is a one-time, so the client can Also cannot be reused.
below is the source fragment of the previous page of QQ:
q the login module on the Web page ( Full Http/get request).
qq when logging in, the user entered the password encryption JS code:
    

function getencryption (password, UIn, Vcode, isMd5) {        var str1 = Hexchar2bin (isMd5? PASSWORD:MD5 (password));        var str2 = MD5 (str1 + uin);        var STR3 = MD5 (str2 + vcode.touppercase ());        Return STR3    }

Vernacular is: MD5 (MD5 (MD5 (password) + user's QQ number) + Verification code)
Now you know how to ensure password security under the HTTP protocol.

Then we're talking about whether we want to save the user's password to the session after the user logs in.

Former colleague wrote the password modify part of the code, found that the user login password exists in the session, and then judge the original password directly from the session read.

Is it safe to have a password in session?
The session is relatively safe to save because the information is stored in the server's
While the way the cookie is not controlled on the server side, it is always a danger to the user information disclosure, but there are also many use cookies to store user information, usually in an encrypted way to deal with.
We often see a lot of site settings remember the user name password, that is, the way to use cookies

I do not propose to do so on the feasibility. even Sun company in is set password time, all use transient to manage, private transient String password, do not want to password serialized out, Therefore, we can not save the password for convenience to the session for convenience.

Finally, we talk about the nature of cryptography: it is actually confusing the original content, and the aim is to improve the cost of achieving the goal from the surface result.
on the issue of Web page submissions (which in fact all communication has this problem), there are several dimensions that need to be secured, First, the security of the aspect, the first protection for a commit is the password itself, from the earliest Base64 to MD5 or Sha can do this, but Base64 is reversible, the password itself is very weak protection, hashing algorithm solves this problem, The different length of the data into a uniform length of large numbers, and theoretically this number corresponds to an infinite number of solutions, but limited to the input of the password limit, in fact, is reversible, so from 1 times the confusion of the MD5 into 3 confused Sha, but with the progress of modern computer technology, the cost of inverse operation is declining, People have to use greater numbers to improve this difficulty, but in order to compromise the cost and development, people have to use a unified algorithm, in the CS era because it is difficult to invade the CS at both ends, so the relative use of the algorithm is confidential, the crack is relatively large, BS because in order to ensure openness, In particular, JS itself is the plaintext algorithm, so in fact can only say anti-gentleman may wish villain, so there is a security control, the sole purpose of the control is to use 2 code to hide the encryption algorithm, do not know the algorithm, it is difficult to crack the original text.

The second dimension is the time, if the password same encryption results will be the same, then in the case of not using the original text, you can use the encrypted data to simulate the user login action is also possible, so pure password encryption actually does not solve the problem, so there is salt value, Let the same data in different circumstances, the results are still inconsistent, but the salt value needs to be agreed, always be identified by the law, but the cost is higher, so it is still unsafe, which raises the issue of communication security. So there is HTTPS using asymmetric encryption to secure the data path, making the communication non-peep. But there is a thing called Trojan, so people in the input continue to make a fuss, including confusing input, is a soft keyboard, good control will not put the plaintext in memory, this is very important, the previous VB, Dephi password control are only invisible, the actual memory is clear, very easy to be used by viruses and Trojans, So generally the safest BS system now uses controls to protect input, hide its own hash algorithm, and protect communications with HTTPS.

I want to cry, I intend to introduce the next article with you digital signature and public key private key, and so on, although I am not dedicated to network communication, but I have the basic knowledge of computer network, and then combined with the development of the angle to talk. Can't you give me some encouragement?

 

Secure login password is not secured in a more robust manner under the HTTP protocol