How to make the site safe during authorization?

I'm not a professional web developer, so I tried to implement authorization on the website as it occurred to me - with the help of cookies. What, specifically, something like:
The user enters the username, password and if they match the database, the cookie records the username and id. So, according to the value cookies['login'], the website determines whether the user is authorized and who it is. But if the user just change the value of a cookie (don't know whether the user can change the value or remove), then the website will think that you're not a van for example, and Peter. You can certainly write cookies in the form of hashed password to each page to verify that the cookie username == dB.login && password == dB.password, but I'm not sure that's right. Or the user does not have access to change the value of the cookie?
June 8th 19 at 17:28
3 answers
June 8th 19 at 17:30
There are browser based cookies $_COOKIES, and have the session variables $_SESSION (ID which is also stored in the cookies of the browser).
In the browser except for the session ID it is better not to store important, because it can change without any problems.
All data for the session to be stored on the server side.
Use the setting flag of the session after a successful login in PHP script on the server side, like so: $_SESSION['user']=$username; everywhere else, check the existence and contents of this variable:
if ($_SESSION['user']!="") { 
 //the user is logged in... 
}
But if one were to keep a severe ID (token) of the user in the cookie?
With sessions more difficult as the standard mechanism implies that the retention time is equal to the SESSION_ID SESSION and then the time will have to increase. If this session gets stolen, it will not be better. - Darius41 commented on June 8th 19 at 17:33
can be whatever you like. The token can also be stolen and in any case you need to bind to an IP address/browser of the user. Therefore, ID-session - in simple cases enough. In complex - already other algorithms. - Kyleigh_Hills commented on June 8th 19 at 17:36
June 8th 19 at 17:32
Can be stored in the cookie can be stored in sessions. Cookies store ONLY a unique token that the theft will stop working. The session can store anything but a standard mechanism raises the lifetime of the session equal to the SESSION.

Most importantly, the session ID is in the cookie (PHPSESSID), many people forget about it. And if you increase the session lifetime, the session == cookies.
that the theft will stop working.
yeah, yeah. would-be programmer will increase the lifetime of the session and do what you want with this token. - Darius41 commented on June 8th 19 at 17:35
June 8th 19 at 17:34
You can certainly write cookies in the form of hashed password to each page to verify that the cookie username == dB.login && password == dB.password, but I'm not sure that's right.

that's right. not safe, but right. not safe because you can go to the browser and steal cookies. but it's a different kind of problem. you can put a lifetime Kuk = 0 and it will be emulation sessions, but without generating clouds of sessional files.

ie

1. The user enters the username and password, they are correct.
2. Set cookies:
- ID - the ID of the user
- HASH - md5(user_password_hash + salt), where
user_password_hash - zaharovoy database password
salt - salt

then each page request will be of the form
SELECT * FROM `user` WHERE `id` = ID_из_куки
then just compare $_COOKIE['HASH'] === md5($user['user_password_hash'] . $user['salt'])

The advantages of the approach never occurs destruction of the "session" (i.e., always the user is logged in) if you don't put the cookies life time = 0. For many sites, where critical security is a very beautiful, easy and simple authorization option.
Sorry, you have a split personality or something?
1. You are in the same line suggest to use md5 and in the same row give the link where it says not to use md5
2. In neighboring response you write
yeah, yeah. would-be programmer will increase the lifetime of the session and do what you want with this token.
and in your reply suggest to do the eternal "session"
The advantages of the approach never occurs destruction of the "session" (i.e., always the user is logged in)
- Darius41 commented on June 8th 19 at 17:37
where I was advised not to use md5? O_o

and in your reply suggest to do the eternal "session"
see, the problem with "fit to PC - steal cookie" is a problem in 99% is not in the plane of technology. therefore, to shout about the fact that cookies are bad, but the session is good - not right. Yes, the sessions provides great protection, but it is redundancy in the form of generating large amounts of session files, the inability to stay long in the system and often authentication. I now have a site where I use cookies for authorization. There is a checkbox "Remember password". If it is not enabled, then the cookie will be destroyed when the browser is closed. Otherwise, I warn you, they say what access other people's to the PC was not. - Kyleigh_Hills commented on June 8th 19 at 17:40
,
where I was advised not to use md5? O_o
directly from the link you gave in the answer

redundancy in the form of generating large amounts of session files
1. What? These files interfere?
2. Who hinders to store session files, but in redis/memcached?

the inability to stay long in the system
You do not know how to configure the lifetime of the session?

frequent authentication
this is a huge plus, not a minus - Jaiden_Mil commented on June 8th 19 at 17:43
,
You do not know how to configure the lifetime of the session?
Can. Theoretically. Nearly no one does. To change the lifetime of the session - a sign of total misunderstanding of the essence of sessions. Session - a SESSION. If you increase the shelf life of the session - you are doing something wrong.

this is a huge plus, not a minus
what's the advantage? - Edwin.Abbo commented on June 8th 19 at 17:46
,
what's the advantage?
you want everyone who can use (even in theory) your computer/phone, able to access Internet banking/steam account/your host/contact, etc., etc. and was able to do anything without a password?

To change the lifetime of the session - a sign of total misunderstanding of the essence of sessions. Session - a SESSION. If you increase the shelf life of the session - you are doing something wrong.
And you clean the cookies implement the same SESSION, and offer to be permanent. That is, you yourself say that you are doing something wrong. That's where the real misunderstanding. - Jaiden_Mil commented on June 8th 19 at 17:49
,
you want everyone who can use (even in theory) your computer/phone, able to access Internet banking/steam account/your host/contact, etc., etc. and was able to do anything without a password?
when you service offers a "stay logged in", type mail.ru or VK, you don't make a tragedy out of it? This is a slightly different kind of problem, weeks design. It is the human factor. - Edwin.Abbo commented on June 8th 19 at 17:52
the answer can be edited and removed from MD5

And then put what is recommended in off the docks tag

The difference between a leaky VC/mailru and the website made you that for the security of your website, you are responsible - Jaiden_Mil commented on June 8th 19 at 17:55

Find more questions by tags PHPWeb Development