SitePoint Sponsor

User Tag List

Results 1 to 25 of 25

Hybrid View

  1. #1
    SitePoint Enthusiast
    Join Date
    Oct 2005
    Posts
    30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Stopping users having multiple sessions at once

    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.

  2. #2
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    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).

  3. #3
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  4. #4
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #5
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  6. #6
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs down

    Quote Originally Posted by logic_earth View Post
    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.
    ------------------

  7. #7
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  9. #9
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #10
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by G.Schuster View Post
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  11. #11
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Same session ID? Uh...don't do that.

  12. #12
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    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.

  13. #13
    SitePoint Guru
    Join Date
    Oct 2006
    Location
    Queensland, Australia
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    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.

  14. #14
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  15. #15
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    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.

    Quote Originally Posted by Aleksejs View Post
    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.
    ------------------

  16. #16
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rageh View Post
    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.
    Quote Originally Posted by 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.
    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.

  17. #17
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Aleksejs View Post
    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.
    ------------------

  18. #18
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  19. #19
    SitePoint Guru rageh's Avatar
    Join Date
    Apr 2006
    Location
    London, Formerly Somalia
    Posts
    612
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    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.
    ------------------

  20. #20
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    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).

  21. #21
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  22. #22
    SitePoint Wizard wonshikee's Avatar
    Join Date
    Jan 2007
    Posts
    1,223
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    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

  23. #23
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    You don't even need to check the cookie for sessions, you can just check using the magic constant SID.

  24. #24
    SitePoint Wizard wonshikee's Avatar
    Join Date
    Jan 2007
    Posts
    1,223
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    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.

  25. #25
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •