I was curious about how passwords filled in the password fields travel from client side to server side. So, I started exploring online articles and using my own knowledge about networks and cryptography, I reached to a certain conclusion. But I still think I don't understand the full mechanism. This is what I know and correct me if I am wrong.
Today most web browsers use HTTPS which is TLS over the HTTP protocol. In this, a session is created between the two sides using handshake protocol in which keys are exchanged for encrypting data. So, when I log in or create a new account on Google, Facebook or elsewhere, these keys are used to encrypt data before the transfer.(including the password).
When the packet reaches the server, it decrypts the data (including the password). If it is a new account then the server stores the hash value of the password or the salted hash value. I am thinking during this time the password is in text form. In case it's an old account, the server simply checks the hash value of the password with the stored hash value of the client.
Is that all or do the websites take special care about passwords for the transfer? What is the situation when only HTTP is being used? What was the scenario before HTTPS came into the picture?
1 Answer
Since the generalization of HTTPS, most sites rely on the SSL/TLS encryption between the client and their site. Then as you said they only store a hash of the password. It is true that between the SSL endpoint and the actual processing, the password is in clear text, but it is assumed to be the same security zone.
In the older days (only HTTP), two ways had been used, none of which were perfect.
Digest variant of BASIC authentication.
The HTTP protocol has provision to transmit credentials in header fields, the so called basic authentication. The user name and password are combined with a single colon and encoded in a variant of Base64. And can be stolen by anybody able to access network data.
To add some privacy, people imagined to only send a hash of the credentials. This was the digest authentication specified in RFC 2617. In this mode, a hash (MD5) of the credentials combined with a nonce given by the server is transmitted. As MD5 is non invertible, an attacker cannot steal the original password. But the major drawback is that the password must be maintained in an invertible form on the server.
Javascript encryption of login forms
This is mainly a variant of the former for login forms. The credentials are hashed client side, normally with a nonce transmitted in a hidden field. Here again the passwords must be kept on the server in an invertible form.
As it is now generally accepted that it is more secure to exchange the plain text password over a secure line that only a hash on an insecure one, those two ways are no longer really used.
