Stopping users having multiple sessions at once

[brangy]

I'm using sessions for a user login and I've realised that if a user is logged in and then logs in on a second machine, the first session stays open. It times out as normal if left untouched but if you continue browsing then it doesn't close.

So, if a user forgets to log out of a public machine then someone else can go straight on it and continue to be logged in as them, even if the user goes home and changes their password.

Is this normal or am I missing something obvious? If it is normal, what's the best way of preventing it?

The only thing I can come up with is to set a random token in a cookie, store it in the database and then on every page view check the cookie value matches the database value. So when the user logs in on the second machine it changes the cookie/database token and then the first machine gets logged out as soon as it views a new page because its cookie value is now invalid.

[samanime]

A simple solution is when they login, record their IP address. Then, when you check if they are logged in, also check if this IP matches the IP in the database. If it doesn't, log them out.

That way, when they log in on the second computer, it records that IP. Then, when a page is changed on the first computer, it sees that the IP no longer matches and performs a logout.

That's a fairly simple solution which is quite effective. The one concern is that if they are two computers behind a router, it is likely that both computers will show as being logged in, and it won't kick them off of either.

You could alternatively record their session id instead of IP and do the same action. This would make it so they could only be logged in on one computer (excluding the 1 in a trillion chance that they get the same session ids, which usually isn't even possible unless you have about a trillion sessions going).

[logic_earth]

Why do you even need to do this? Why not keep a record of which user has which session ID, when they login merge there guest session data with the previous session data of that user and give them a fixed session ID or alter it but record the change of the new ID.

[G.Schuster]

What I've done for a client ist store the session in database.
This way I'm able to see if the requested username is already logged in.
If so, I display a message that there's already a session and if they contiune to login the other session is destroyed.
As PHP supports custom session handlers you even don't need to use any crptic functions - you can still use $_SESSION and all related functions.

[logic_earth]

Maybe I'm missing the point, but why in the world would you need to something so limiting? Why can I not be logged into two computers without messing up or ending the previous login? I mean try it here on Sitepoint. I'm logged in on my laptop and while I'm on the road I can use my phone and login. Now that doesn't affect my laptop which is still logged in go figure.

Also since I am on a laptop using the same computer but if I go to work with then try to login after i did at home am I considered using a different computer even tho it is the same one?

[Aleksejs]

logic_earth, different systems require different approaches, what is good/convenient for forum is unacceptable for payment system

I would prefer that upon logon I could see active sessions with my credentials and have choice to terminate any of them. Also a log that shows times and IPs from last logons would be great.

[logic_earth]

Perhaps the payment gateway systems you use are completely different then what I use.
Because all the ones I used are time based, if the user doesn't do anything for say 5 minutes they are required to log back in making it irrelevant for maintaining multiple sessions for a single user.

[G.Schuster]

Well, just think of a callcenter-app.
A call agent should only be logged in once because otherwise he would be assigned multiple calls - that has to be prevented and therefore you only allow one session for a single username.

[logic_earth]

Well, just think of a callcenter-app.
A call agent should only be logged in once because otherwise he would be assigned multiple calls - that has to be prevented and therefore you only allow one session for a single username.

You should then give the username the same session ID each time, in essence keeping a permanent session for that user. But it only becomes a problem if the user uses a different browser unless of course the browser is set to create a new session cookie on new tabs or windows not likely.

[G.Schuster]

Same session ID? Uh...don't do that.

[samanime]

I actually ran into a scenario where a solution like this was needed. At my work, we have our own intramail. It's at a university and everyone there is a student worker... and they like to play pranks like changing others look to be all a solid color making it annoying to navigate.

So, we wanted a solution where if you forgot to log out at one station, but logged in somewhere else, that it would log you out in the first place so you didn't have to worry about it.

There are practical, mostly security, reasons.

[rageh]

Maybe I'm missing the point, but why in the world would you need to something so limiting? Why can I not be logged into two computers without messing up or ending the previous login?

I was explaining to client how to set up and tweak Paypal over the phone. Such information as date of birth and so on was being asked by Paypal and I did not want to know about it. I told the client to fill in those details by himself. But I had to be logged in with his details to show him around in the system. When he had logged in, Paypal booted me out unceremoniously expiring my session. The point is that the client and I were logged in from two computers at the same time for legitimate reasons.

Sometimes you wonder if these over cautious restrictions are not disruptive more than anything else. If I was up to no good, the probability of me logging in exactly the same time as the legitimate account holder would be nil. Even if we coincidentally log in exactly the same time, one of us is booted out. If it is me, I can log in again in few hours. Big deal. I think trying blindly to stop two people logging in at the time without thinking what if the thief logs in a bit later is ridiculous and achieve nothing.

[Aleksejs]

rageh, you have a good point.

However the decision on weather to allow simultaneous logins or not depends on requirements.
As Bruce Schneier says "Security is a tradeoff" - if you have assessed risks correctly and have come to conclusion that "profits" from simultaneous logons outweigh "losses" that arise from this decision, then by all means make simultaneous logons possible.
Take into account however that the idea of simultaneous logons is considerably more complex (and complexity is the worst enemy of security) than the idea of exclusive logon - there are just more places where to go wrong. With simultaneous logons for instance a whole sack of race condition horrors opens up.

As I earlier mentioned I would be more pleased to have better accountability and control of active and past sessions.

P.S. Does PayPal differ so much from user to user, that you could not explain to client using your paypal account as an example on your side and letting him open his account on his side?

[Jake Arkinstall]

explain to client using your paypal account as an example on your side and letting him open his account on his side?

Different users have different types of account, and if you're guiding them through adding cards to the account, you'd need to remove yours then add it again - paypal would probably freeze your account if you did this too much.

Not only that, but if the client gets a message that you don't, which is because of his account, then you can't help without spending ages guiding through it blind.

However - if you use a remote-desktop program, you could guide him through everything as if you were sitting next to him.

[Wardrop]

It's at a university and everyone there is a student worker... and they like to play pranks like changing others look to be all a solid color making it annoying to navigate.

So, we wanted a solution where if you forgot to log out at one station, but logged in somewhere else, that it would log you out in the first place so you didn't have to worry about it.

Your solution is still flawed as a user may not re-logon for hours if not days which gives 'prankers' plenty of time to do their worst.

Asking someone to re-enter a password when they attempt to make any major changes (depending on what is considered major) is a reasonable solution to such an issue as it's always active. For example, if I pushed Joey Jones off of his computer while he was logged into his webmail, I wouldn't be able to change his theme as I wouldn't know his password.

You need to be careful with this approach though as if over-used, it can annoy some users.

[samanime]

I agree, and I favor timeouts. My boss was the one who wanted the change because the current intranet (which existed before I got here) doesn't timeout or only allow single users.

My boss is kind of goofy some times, but there is little reasoning.

However, I was just using that as an example to show that there are cases in which it is reasonable to allow only one login at a time.

Another scenario could be something like an online RPG game, which would force you to only have one SESSION at a time. (That's a better example).

[Jake Arkinstall]

For such a thing, I would use a method I think I saw felgall mention:

1. When user logs in, generate a random key and put it on their row in the login table, also put it in the session
2. On every page load, query the database to check if the field and the session are the same
3. If they aren't, log out the user

[rageh]

rageh, you have a good point.

However the decision on weather to allow simultaneous logins or not depends on requirements.
As Bruce Schneier says "Security is a tradeoff" - if you have assessed risks correctly and have come to conclusion that "profits" from simultaneous logons outweigh "losses" that arise from this decision, then by all means make simultaneous logons possible.
Take into account however that the idea of simultaneous logons is considerably more complex (and complexity is the worst enemy of security) than the idea of exclusive logon - there are just more places where to go wrong. With simultaneous logons for instance a whole sack of race condition horrors opens up.

My point was that if the hacker has the login details, he can login from any machine any time. It does not necessarily follow that the hacker will have to be logged in at the same time as the legitimate account holder. In other words, Paypal is defending itself from simultaneous logons without asking themselves how can we stop that attacker from logging in later alone? They can't. The fact that the attacker gets hold of the login details is the main threat, which these "simultaneous logon preventions" do not account for.

P.S. Does PayPal differ so much from user to user, that you could not explain to client using your paypal account as an example on your side and letting him open his account on his side?

Yes it does in a way. I have a verified account with no sending or withdrawal limits. But a new member has to have his bank and address verified before he is awarded that privilege. For that to happens, he has to provide slew of information that I am not asked when I login my own account. So I have to tell him not only where to click but what information to fill in.

[rageh]

Different users have different types of account, and if you're guiding them through adding cards to the account, you'd need to remove yours then add it again - paypal would probably freeze your account if you did this too much.

Not only that, but if the client gets a message that you don't, which is because of his account, then you can't help without spending ages guiding through it blind.

However - if you use a remote-desktop program, you could guide him through everything as if you were sitting next to him.

Exactly arkinstall.

As regards the remote-desktop program, the client must download and stall the program in his machine for this work. In this case, the client is not web savy enough to know the downloading and installation process necessary. It might as well take just as long to explain all that over the phone than to directly show him around while he is logged in his account.

[wonshikee]

If you are using a database for your session data, when they login -
create a cookie if there is not one already - and store it in the session.

Upon every request you would check the cookie's value against the session.

If they don't match - then it's a different browser/system

[samanime]

You don't even need to check the cookie for sessions, you can just check using the magic constant SID.

[wonshikee]

Didn't mean to store the session ID in the cookie, i meant put a unique key there that is independent of the session id.

This allows you to check that the cookie is unique and I would think is a relatively reliable way to ensure a singler user is logged in.

[Aleksejs]

My point was that if the hacker has the login details, he can login from any machine any time. It does not necessarily follow that the hacker will have to be logged in at the same time as the legitimate account holder. In other words, Paypal is defending itself from simultaneous logons without asking themselves how can we stop that attacker from logging in later alone? They can't. The fact that the attacker gets hold of the login details is the main threat, which these "simultaneous logon preventions" do not account for.

Actually more often than not attacker does not have to have logon details (if by them you mean username/password), but just the session ID of an active session.

Putting debate on simultaneous/exclusive sessions aside. The problem that brangy wants to address is that: If session remains open, then user is left with no way to terminate that session, other than go back to that particular computer and destroy session data (log off/clean cookies). The problem that has to be solved somehow. With exclusive logon the problem is solved "by definition" - once you log in somewhere else, then all other (well there should not be more than one other, really) sessions become invalid. With simultaneous logon some kind of "session control panel" must be developed, so that you can choose which sessions to terminate and which to let remain open.

Didn't mean to store the session ID in the cookie, i meant put a unique key there that is independent of the session id.

This allows you to check that the cookie is unique and I would think is a relatively reliable way to ensure a singler user is logged in.

Well - session id is kept either in cookie or passed via URL (GET). So if you just add some unique key, then it does not really solve problem. You can look at this as increasing the length of session id.

You could try storing this key in browsers scripting state though - if your application is very dynamic in nature and requites JavaScript on clients side, then you could try to assign this key to some variable and append it to every request, that your browser sends to server.

[rageh]

If session remains open, then user is left with no way to terminate that session, other than go back to that particular computer and destroy session data (log off/clean cookies). The problem that has to be solved somehow. With exclusive logon the problem is solved "by definition" - once you log in somewhere else, then all other (well there should not be more than one other, really) sessions become invalid.

With simultaneous logon some kind of "session control panel" must be developed, so that you can choose which sessions to terminate and which to let remain open.

I take your point. It is a valid point in that if the user forgets to log out in one computer and logs in another one, one of the sessions must be destroyed. But before the destruction, it makes sense if the account holder, after a second login is detected, is notified that there are two active logons and then he decides what to do about it. Leave it as it is or destroy it.

Microsoft MSN implements something similar. If you log in from another machine again, it automatically expires the older session but at the same gives you the opportunity to login again on that machine. But it still does not let you decide which session keep.

[Aleksejs]

So from the usability perspective I see that proper solution would be:

• In case of exclusive logon: A message: There is an active session from address X that has been idle for Y minutes. If you proceed then it will be terminated. Do you want to proceed? There must be possibility to view all past (or maybe just last N) sessions with details (when/how long/from where/what was done).
• In case of simultaneous logons: When logon is confirmed a clear message: There are X active sessions. And possibility to view all active sessions with details and with means to terminate any of them. And also a history of past sessions with details.