Remembering logged users & only one logged user per username?

[Koobazaur]

Hello, I searched for this topic but did not get too many results.

 

Basically I have a system that allows users to register an account and log in. I want to give them the option of rembering thier login so they don't need to re-type it every time. One solution I found was to simply store login/username in a cookie and retrieve that when login page loads. That, however, seems like a huge security risk, so I am looking for a better solution.

 

One idea I had was to, when a user logs in (and chooses "Remember me" checkbox), he is then sent a cookie with a randomly generated "Login Key." This key is also stored in the database. When a user comes back and enters the login page, the code tries to find the login key in the database and if a match is found, it then logs the user accordingly. Of course, on logout, such cookie would be destroyed. Is this a good way to go about it or does anyone have better ideas?

 

------------------------

 

Another thing I need to implement is to allow only one logged user per username. That is, if someone logs into his username, I do not want to allow anyone else to log in from another computer into the same username. Naturally, I cannot simply set some flag in my DB when user logs in and unset it when he logs out because there is no guarantee my user will actually log out every time (he may simply close the browser window, thus losing the Session Cookie, losing access to his account but unable to re-login due to the set flag). Thus a more complex system is needed.

 

I thought I could set an entry in my database to mark the user has logged in and additionally assign some random key to go with that, which would be also sent as a cookie to the user. If the user attempts to log in and the database already marked him as logged, then he will be allowed to log in only if he has the cookie with appropriate key. Of course, when he logs out, the logged flag, key and cookie would all be erased to allow a fresh login from any place.

 

The only flaw of this system is if the user accidentally deletes his cookie with the key and shuts down the browser, losing his session information. In such case, he would need to wait for the session to expire before he can log in again (a fixed amount of time which I haven't decided upon, but may be something like 24 hours). This would create a wait period which the user would have to wait out before he can log in again. I cannot shorten this priod via idling-out mechanism as the way my session handling is implemented it does not require database access once the user is logged in, in order to minimize used traffic and database time.

 

Any suggestions are much welcome!

 

[Buyocat]

In reverse order:

 

Why not have a table which has

1) the user's id

2) the user's ip (why not?)

3) the user's session id

4) a timestamp for when the session id was issued

 

You would then keep a user logged in based on id, ip, session, and time.  If the ip, session id changed you would delete the row thus logging out the user.  If the timestamp were past a certain point it would no longer be fresh and would prompt a re login.  This would be roughly equivalent to storing a cookie.  If you made the lifetime of a session infinite it would be equivalent, assuming that the user's ip doesn't change frequently.

 

As for keeping the user logged in.  Insofar as I haven't already addressed that I would say that you could hash the session id and user id and store it in a cookie without any security implications.  In fact that hashed composition could be another column in the session table, and a constraint can be added dictating that the values in that column be unique.

 

Sound good?  Let me know if you have more questions/to discuss.

[448191]

Why not simply use session_set_cookie_params($someNumberOfSecondsSay2635200) ?

[Mastodont]

One solution I found was to simply store login/username in a cookie and retrieve that when login page loads. That, however, seems like a huge security risk ..

 

If you divide users into groups, you can safely let auto-login all users from nonimportant groups (guests, "comments-makers" ...).

 

There is a bunch of published solutions for logging, no need for reinventing a wheel.

[Koobazaur]

Buyocat, thanks for the reply. Your idea is interesting, but I can see one flaw. You say that "If the ip, session id changed you would delete the row thus logging out the user." However, this means that if someone else tried to log into that account it would then erase this information, thus logged the original person out of his account - not a desirable outcome. And the IP changing frequently is a concern since my website will be targeting college students which will most likely have dynamic IPs.

 

Also, wouldn't your solution require me to access the database each pageload in order to verify that the log in is still correct and not expired? Currently all this is done via session variables without any database access (aside from logging in and out) and I would like to keep it that way so to minimize the database traffic. Or am I simply being too careful and should allow database access to verify session info each pageload without any serious slowdown? (I use MySQL)

 

448191 - I didn't think of that, I suppose that could also be a viable solutions. Does it have any drawbacks / security issues though (I can't think of anything that would make storing a session id permantently any less secure than my login key idea)?

 

One solution I found was to simply store login/username in a cookie and retrieve that when login page loads. That, however, seems like a huge security risk ..

 

If you divide users into groups, you can safely let auto-login all users from nonimportant groups (guests, "comments-makers" ...).

 

There is a bunch of published solutions for logging, no need for reinventing a wheel.

 

It's the important group that is really... well, important.

 

And what published solutions are you speaking of? Any links?

[Buyocat]

Well I have a few things to say in response to your concerns.

1) Doing a db query is worth it.  I believe this is the case because a. you'll most likely be peforming more queries anyway, so the effect of one more is small. b. you escape relying on the client as much as possible. c. by storing the data you can mine it in the future for useful statistics. d. relying on the database for sessions means you can scale this process out very easily.

2) As for logging user's out that would be your responsibility.  So if user A is logged in but a second user B attempts to log in with the same credentials you could either delete user A's login-row or you could deny user B.  I would do the later.

3) I see that IP addresses could become a liability, but I wasn't saying you had to use them.  You could mix and match the data I suggested with additional data of your own to find the right balance between relibility and security.

 

Overall I think moving sessions to the database makes the most sense.  You're right that you'll incur a little overhead vis a vis the query, but to be honest a single query is not going to have a noticeable affect on your page loads.  The benefits though are staggering.  I'll just underline again the issue of scalability.  In the future you may find yourself with many frontend machines.  If you store session in the database you can manage it through a single backend machine as a service.  This means you can put responsibility for session tracking across multiple machines into a few backend machines.  More importantly, if you went with cookies or another client-based approach you would run into aberrant behavior as the user may be served by different front end machines on each request thus complicating the issues client-side state.  Whereas a call to a single service which maintains user state would escape this problem.

[Mastodont]

what published solutions are you speaking of? Any links?

 

Try for exmaple:

http://php.resourceindex.com/Documentation/Examples_and_Tutorials/User_Management/

http://php.resourceindex.com/Complete_Scripts/User_Management/