How to transfer the password from the browser to the server, how to store it on the server and check the correctness?

Question

PHP

Hey!
The password must not be sent in clear text over the network.
And also the password should not be stored in clear text on the server.
It turns out that we should send not a password, but a hash from it and a salt, which was sprinkled with the password during hashing.
But we don’t store the password on the server either, but we also store its hash and salt.
Then I got confused.
Here we have the hash and salt received from the browser, and the hash and salt stored on the server.
AND? What to do with it?
How to check that the password is correct?

Answer 1

Depending on the degree of security.
If you break it all down into "easier", the general principle is as follows:
- enter a line of text for the first time
- press send
- do not enter again, because he is a lazy person, and we are going to sell him, God forbid he will feel
- get a line of text
- make a hash
- check - whose hash it is (whether it was stolen on the way)
- send a token in response, which will work for a limited time only for this computer
- save the token on the user's computer, and next time send it automatically for every action without the knowledge of the user
- update the storage time of the token with each action (some especially crazy people make a new token every action)
- at the slightest suspicion of a token mismatch - a suggestion to politely go through authorization again, but since a person is a funny creature - if he is told to enter the password again - he will be offended by a bitch , and therefore a "two-stage" was invented - through a phone or there is a fingerprint or anything else, and it's useful - if the password is really stolen - cut off your finger and tear out your eye - this can still be done together, but by soaking a person - ask his mother to enter the code that came from the SMS - this will already have to deal with blackmail.
There are also a lot of local storages:
- cookies (stored directly in the browser for a specified time)
- sessions (stored on the server, but in cookies there is a key to a cell in the "bank", which again can be stolen)
- ... dozens of other ways that only cool coders know about, who consider themselves cool simply because they are known , in fact, from the point of view of creating value for people - useless knowledge
. As you understand, this is an illusion of security, not a guarantee.
The token will be stolen - and that's it, the server can be deceived. Therefore, all sorts of checks are made on the server, such as sewing into a token - the IP address, the size of the user's screen, his fingerprint, the retina, the user agent, the device - and somewhere even some smart guy wrote a whole lib who managed to use this hash almost a thousand different parameters to shove.
Here is another topic that Vasily said - to encrypt the password already on the client side at the time of submitting the form with Javascript. Imagine yourself as a hacker. You received some dude's packages, set the computer to decryption by connecting a dozen video cards, decrypt the password, and instead you see a 64-character hash, that is, it came out like that directly from the client. After that, there will be mats from the fact that now the vidyuh array needs to be forced to also tear out the key phrase from the hash. Well, that is, the decoding time also increases. If you drive it, then the hash can be not just an md5 () hash, but for example, md5 from md5 from an unfolded string added to md5 () of a direct string, thrown through a bitwise shift by one bit - well, that is, even encode a sequence of actions in this. In the absence of https - the most reliable way.
And then - Yii programmers do not recommend using the md5 () function. Why? Because she is very fast. And when brute-forcing the password with an array of video cards, it gets over very quickly. Therefore, it is recommended to use the hash function, which takes more time to create a hash, say a few seconds. When writing a synchronous program (a site in php, for example), this will force the user to wait 3-4 extra seconds after registering, but if you get tired, the password generation process can be pushed into asynchronous mode, and the user will immediately be given a token, that is, a password will be generated for him a little later. Thus, due to the longer hash function in time, the hacker will need much more time - that is, the user will need 5 seconds to directly create a password, and the hacker will need several years to enumerate several million passwords. No one will pay him 10 mower bucks to break your fucking VKontakte password. If the banking sector - again, as I wrote above - hash from the hash, expand it a couple of times, chop it three times, then knock on the tambourine and all this into the hash again and voila - decoding the password will take 100 years.
It also means that at the slightest hint of a token mismatch or a sudden change - the server says "bye, uncle, let's go through the second stage of authorization, otherwise I don't believe that it's really you" and asks to put a finger. Or enter the number by receiving SMS. Or insert the blue key card (duke nukem hello). But even here there is a hack - steal the key card, sms-ku - ask for a phone, put a finger = cut off a hand, tear out an eye, etc.
Here https comes to your aid. Https is such a thing that in a nutshell can be called a game of partisans. In the war, they played like this - when radio communications were tapped, and there were no scramblers - the only means of protection was to use errors in the text and swear words.
So here - the data sent in the form of zeros and ones. Computers can just as easily recode them into a password as they encoded them. To prevent this from happening, they came up with the ENCRYPTION of the line in one direction. The server has a stencil, the user has a different stencil. The server encrypts with its own, but can only be decrypted back by the user. Or rather, it can be third-party, of course, but modern computers will do it for many years, and therefore no one bothers too much, the performance is not the same.
Thus, sites that have https are currently the most reliable way to hide zeros and ones from the dude sitting on the wiretap of your Internet traffic. And he can get there from the simplest ways like “friend, give me the password for your Wi-Fi”, to all sorts of guessing, hacking routers, and at worst - under the guise of an electrician, installing a small fee in your switchboard.
So authorization is simple. All hope for encryption. And the certificate on which half the world makes money is a means of confirming that the computer can encrypt. Interestingly, it ends every year, as if last year the computer was able to encrypt, but suddenly forgot how to do it this year. In fact, of course - just drive the loot, otherwise we will show a red cross instead of a green lock, and lower it in Google, so drive the money. Here.

Answer 2

The password must not be sent in clear text over the network.

where did you read this? The password should not glow anywhere when entering and sending, so the password field is made with asterisks, and the post method is used to send and not get, so that the password does not glow in the browser line. To protect against mitm attacks, they use https, although with the right approach this is also not super protection, keys can be intercepted, it gives some protection, but if the key exchange session is caught, you can already score on HTTPS protection.

And also the password should not be stored in clear text on the server.

Logically, perhaps the only logical line in the post)

It turns out that we should send not a password, but a hash from it and a salt, which was sprinkled with the password during hashing.

It doesn't work, we send the password without knowing the salt, that's the whole point )) The server accepts the password from the user (open), hashes it with the salt (known only to the server), and compares it with the one stored in the database. If the hashes match, the password is guessed correctly)

Answer 3

Use encryption on the client and server side for communication, AES + RSA (or something else but with a similar essence ... ).
Open key to closed and forward with the song. For each session, generate new keys or even for each attempt... The password input field is collapsible from pieces, it is possible to transfer markers for each attempt along with the key, enter not from the keyboard, but generate a popup with a random position of the content, including numbers without the possibility direct links to such .... But all this will only complicate the possibility of hacking ... whoever needs it badly will sort it all out and get his opportunity ... Everything that is on the client side, everything is always vulnerable ... The only question is wasted resources...