Is the authorization algorithm for Session and Cookies correct?

Question

PHP

Good afternoon.
I do authorization on my site through sessions and cookies. I came up with an algorithm, but I'm not sure if it's correct. Please help me complete and correct it.

Algorithm

When the user sends his login and password to the server, they are checked and if everything is fine, then an element with the index 'username' is added to the $_SESSION superglobal array , in which the user's login is recorded and cookies with the same username are sent (here in this place, I there seems to be some kind of strong security hole).

Further, when I need to get information about the client (about whether he entered the site or not), I implement the following algorithm: 1) if there is a cookie with his name, then add a session with his name; 2) if there is a session with its name, then we do nothing (because the cookie could end its life due to its storage time); 3) if there is both a cookie and a session with its name, then we do not make any changes; 4)if there is no cookie, no session, then we also do nothing.

Next, we simply check if an element exists in $_SESSION$ with index 'username', and if it exists, we treat this client as an authorized user.

I think this algorithm is very strange in terms of security. Help, please, bring it to mind.

Answer 1

If it was a horse, I would recommend shooting it, sir!
Any student can send a cookie with the name "Admin" in the request.

Answer 2

Why send cookies to the user? Just remember all the necessary parameters in the session, the web server itself will send phpsessid and then the user will only walk with it. Well, if you care so much about security, binding the session identifier to IP and / or user agent will be useful.

Answer 3

1) if there is a cookie with his name, then add a session with his name

So by setting a cookie with any name, I will be logged in under this user.
Why think about the bike, when usually if the login / password is correct, we put a username in the session, and that's it.

Answer 4

The algorithm proposed by you is erroneous in terms of security.
Usually they do this:
1) When registering, a new user sets a password, which is encrypted with a random “salt”. The user is sent as a cookie with his ID (to speed up queries), login and encrypted password. The database contains ID, login, salt and encrypted password.
2) During authorization, cookies are checked, if they are correct, then we create a session and put the necessary data into it. If something is wrong with the kukak, then we delete them on the server and on the client using JS and transfer them to the authorization form.
3) When updating the page, we check the cookie and session data, if everything is correct, then we work. If not, then we clear the session and log in through cookies. We do not store the password in the session.

Answer 5

Be sure to bind the session to an IP. For cookie authentication, you need both a username/ID and some hash (maybe a password hash). Of course, you can also make a hash based on IP for cookies, but when you change IP, authentication will be needed. Automatic login to the site is always a security hole. I solved this problem for myself like this: if the user logged in through a cookie, then on protected pages we ask you to re-enter the password.

Answer 6

Why are you sending cookies yourself? Cycling again ... If you use $_SESSION, then use session_start(), it will generate a hash and send a cookie. And if you make your own mechanism, then $_SESSION has nothing to do with it.
In general, start with the documentation

Answer 7

bit.ly/Me3uY8

Answer 8

> (here, it seems to me, there is some kind of strong security hole)
One id is not enough, in parallel with authorization, you need to generate a random sequence of, say, 5-6 characters, then hash it, write the hash to the database and put a cookie with it hash.
When changing the page, check the id and hash of the client, with those in the database, if they match, then the user is the same.

Answer 9

denver , a new hash is generated with each login, as a result, the last logged-in hash will remain in the system, I don’t see hacking here at all
... login "will give a ride ... But here one more question arises. What if an attacker finds out the password?

Answer 10

denver , a new hash is generated with each login, as a result, the last logged-in hash will remain in the system, I don’t see hacking here at all
... login "will give a ride ... But here one more question arises. What if an attacker finds out the password?

Answer 11

denver , a new hash is generated with each login, as a result, the last logged-in hash will remain in the system, I don’t see hacking here at all
... login "will give a ride ... But here one more question arises. What if an attacker finds out the password?

Answer 12

denver , a new hash is generated with each login, as a result, the last logged-in hash will remain in the system, I don’t see hacking here at all
... login "will give a ride ... But here one more question arises. What if an attacker finds out the password?

Answer 13

Make hash with username+password+ salt store it in session, cookies and database.
And check for a match each time.

Answer 14

Oh, sorry, something habr is stupid ...