How does password authorization work in web applications?

Question

C++ / C#

I'm starting to learn web development from the backend side.
Please tell us in a nutshell how authorization works in web applications? Or give a good link...
The situation is something like this:

• writing a static HTTPS server in C++ (using Poco to reduce the number of bicycles);
  
• the server should give html-pages (and other accompanying js-scripts, css-files, pictures and just arbitrary files) only to authorized users;
  
• if the user is not authorized, then return: 401 Unauthorized
  
• user credentials are stored in a text file (so as not to complicate the work with the database).
  

configured certificates. just pages to everyone already gives out.
In theory, the login / password in clear text should not be transmitted and stored on the server.
I have not used cookies yet, but theoretically I understand it as: some key-value dictionary, which the client passes to the server every time it is requested, but can be filled by both the server and the client (Is that right?).
As I understand it: the server, when checking credentials, makes sure that the current session is "good" and sculpts a certain ID in cookies, and this ID itself remembers in the list of "good". The next time the request comes with this ID in the cookie and you do not need to log in again (Is that right?).
Here I spied that it is optimal to use HTML headers to transfer credentials.
But how to do that? And what is salt? Is it stored in that text file? Or is it one shared per server? Or is it generated for every request? Or an answer?
In general, if you specify:
what to do with the login / password before passing it to the server?
what is stored in the credential text file?
how is the procedure for checking for "goodness" on the server?

Answer 1

Usually separate sessions and authorization:
Session . To implement a session, the server, on the first connection with the client, can generate some random token and set it in cookies. It is important here that cookies must be transmitted over a secure channel (HTTPS). This way you can save some session information in the database or in the cookies themselves, but then you need to sign the cookies so that the user cannot change them.
In any case, the server will store information about active sessions in the database.
You can sign cookies, for example, by adding some HMAC in addition to the information you need .
Authorization. The server never stores passwords. The database stores the login and password hash (actually not). For authorization, the user sends a login and password (HTTPS). The server calculates a hash from the password and, if it matches, the session is marked as authorized.
Salt . Now let's imagine that you actually store the username and password hash in a table:

login | pass_hash
------+----------
vasya | 4B32E1C...

In an ideal world, this would work well. But in the real world, 90% of your users will have a password like 12345, password, password123, etc. Accordingly, there will be many identical hashes in the database, and it will not be difficult for an attacker to quickly guess the passwords of most of your users.
To do this, for each user, the server stores some unique random data (salt). And instead of the password hash hash(pass + salt), .

login | salt   | hash
------+--------+-----
vasya | 4B3... | 2A3B9...

Thus, it becomes more difficult to search for passwords in a dictionary.
Hash . Perhaps you have seen or heard about MD5 somewhere. Now, MD5 is not a secure cryptographic hash function today, and even if you apply MD5 a hundred or a thousand times, it won't make much of a difference. Today it is recommended to use SHA-2 or SHA-3 .
PS Salt and tokens must be generated using CSPRNG .

Answer 2

Password authentication is the century before last.
In the same article to which you gave a link, please pay attention to the "Authentication by tokens" section.
VKontakte, Facebook, Yandex, Google, Mail.ru, etc. - choose an account provider to your liking and you do not need to worry about storing and transferring passwords, and users - with inventing these passwords, forgetting them, restoring them, entering from the keyboard and other hemorrhoids.
Type in the search engine: oauth <my favorite provider>, and get detailed instructions on how to implement it.