I want to make an authorization system, but I do not fully understand how much the system with COOKIE is safe. I do this:

  • user logs in, enters login and password
  • we "salt" the password with a login and save the hash function in the database
  • when the user enters his login and password to log in, we again get the hash function from the login and password just entered and compare the value with the function that we have in the database
  • if these hashes match, then we salt this hash on time or on ip and give the resulting value as COOKIE to the user. And the same value is written to the database in a cookie column for example.
  • and now when a user visits our website, we check if he has a COOKIE and compare them with the value that we recorded in the cookie column in our database.
  • if these cookies match, then the user is successfully authorized.

And it turns out that if these cookies are taken from the browser and copied to another computer and access our website from this other computer, the server will check if there is a COOKIE with this value in our database and, if so, then skip the user without any problems. And even if we specify the validity of COOKIE one day for example. We then recorded this cookie value in the database forever. It will not be removed from the database in a day. And theoretically, if an attacker once acquired the value of a COOKIE, then he will always be able to enter the site and be considered authorized. If someone can clarify the situation. I would be very happy. Thank !

  • I would like to add one more important thing as a csrf token. I recommend you to use in all forms on the site where there are POST requests - Evgeniy Mikhalichenko

1 answer 1

we "salt" the password with a login and save the hash function in the database

Don't do that. Already, even the core added functions specifically for handling passwords.

And do not do anything else with this hash. Need some kind of token for something? There is random_bytes (and the php version is not an excuse, the manual has a link to the implementation in user space).

We then recorded this cookie value in the database forever. It will not be removed from the database in a day. Since a user cannot trust a cookie's lifetime, it means that you need to keep his lifetime near the token.

Accordingly, when you authorize, you generate a token. Since the piece is important for security, it is only through CSPRNG , a crypto-resistant generator. No rand , mt_rand or shuffle . The resulting token is stored in some storage on the server. I can name two options:

  • write the token to the user nameplate and the date of issue of the token. Then check both token and date, was it too long ago?
  • write a separate label: user_id , token , valid_until . You can still ip , user agent and still nice to show the user "recently you are logged in here and there." For each authorization received their token and their time of life, if necessary, you can shoot selectively.

(plate - the concept of figurative. It can be stored anywhere, and not just in RDBMS)

Do not forget to reset all tokens when changing the password. And do not forget to set optional parameters for cookies, httponly exactly, secure - if you are puzzled by the https setting.

Purely for convenience, you can still save user_id in the cookie. By itself, publishing an id is not dangerous and often id is generally publicly available, for example, in the profile url on the site, but it’s easier to search for it.

  • If I understand correctly, then this token must be passed to the user in cookies. And for each token I have an expiration date on my server. And if this expiration date is shorter than the time on the server, then it is invalid and the user should be asked to log in again. And theoretically, this token from cookies can be copied to another computer and from there to come without problems? And I can’t verify it in any way and this is the most basic vulnerability of these COOKS as I understand it, yes? and so that copying cookies is not a vulnerability, do you need to use sessions? - dhNkolas
  • @dhNkolas, do not you know where the sessions store their identifiers? Yes, yes, in the very same cookies that you are so worried about. Cooks are not just created so that all and sundry stole them. Yes, cookies can be physically copied from one computer to another, but these are not your problems, but the problems of users who should be concerned about the security of their computers. You are doing emphasis on cookies, and the fact that all traffic and all data on the road between the user and the server can lead to the side did not think? ;) - Visman Nov.
  • @Visman is now more understandable. Thank you) - dhNkolas