Remember me, cookie, do you need a session cookie?

When a user logs in to my site, he creates 2 cookies, one with a session ID (which refers to the user ID for the backend) and a cookie that lasts 3 months.

Remember that a cookie is created as:

userid:timeout:hash 

If the hash is an HMAC SHA256 userid:timeout hash to prevent tampering.

If the session identifier does not exist (the user closes his browser and reopens it so that the cookie disappears or the session identifier does not exist in memcached), he looks at the cookie and re-creates a new session cookie, provided that it has not been set and hash correct.

However, I see no reason to have a session cookie at all, as the session id simply points to the user id in the backend. Instead, I can use cookie memory to load the current user.

So, I think that I completely refuse the cookie session, and I will be interested to hear some thoughts about this. Is this approach relatively safe? Can I do it better?

Thanks in advance!

+4
source share
1 answer

Yes, it is really safe enough for most cases, but why include user data in a cookie when you can avoid it? In addition, there is a slight drawback:

What happens if a user manages to steal a cookie from another user, you will have to change the whole way cookies are created or so that the user always has access, so reset all cookies. Imagine this is your cookie that is stolen ...

This is my solution for this: create another row in the user table named userhash. When a user logs in, you generate a random hash without any input, just random and save it both in a table and in a cookie. Then you need to save userhash:timeout in a cookie. You check this against the database to see if it exists, if so, what your user is. When a user logs out, the cookie and row in the database are deleted. For obvious reasons, you will need to check if the cookie exists before the comparison (there will be many empty ones).

Note. This method would only allow one registered cookie, so the laptop and desktop would not. This is good because theft is getting harder because it lasts until the real user logs in, and bad because it only allows one computer. But you see the idea and how you can use this method, but have several computers that are logged in ... facebook-like.

PD, it would be nice if you said how secure your application should really be ...

PD2, if you have not thought about it, there are other serious security problems (for example, SSL).

+1
source

All Articles