SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 29
  1. #1
    SitePoint Zealot Oggle's Avatar
    Join Date
    Jul 2003
    Location
    Cali
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Session Management

    I'm trying to create a script that has the option "keep me logged in on this computer", which will store a cookie on the user's computer and keep him logged in forever, until he logs out.

    The thing is, I'd like the user to be able to log in at the same time to more than one computer. Perhaps he has a login from his work computer, and one at his home computer. I want both sessions to be kept if someone did that, and not log one out if he logs in at another computer.

    Now my question is, how best to store the session key in the database so that this will work?

    Should I store a sesstion key (long random string), and in the cookie store the username + session key ? The downside would be that this cookie would always remain the same forever, which might not be the best for security purposes.

    Any suggestions?

  2. #2
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,806
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    in that case you would have to store his logged in state in the database as there would be no opportunity to set a cookie or session. This would be very difficult to manage and security would be exceptionionally tricky.

    It would just be easier to get them to log in again!
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  3. #3
    SitePoint Zealot Oggle's Avatar
    Join Date
    Jul 2003
    Location
    Cali
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How do sites manage to keep users logged in forever then?

  4. #4
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,806
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    By setting a lifetime cookie, which sites allow you to log in and then go to a different computer and still be logged in?
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  5. #5
    Non-Member
    Join Date
    Jul 2005
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if you base the session key on their ip it doesnt matter, all you have to do is make sure you allow a person to have more than 1 active session.

  6. #6
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,806
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    it does matter if the person is using a dynamic IP as it wont be the same.....
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  7. #7
    SitePoint Zealot Oggle's Avatar
    Join Date
    Jul 2003
    Location
    Cali
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There's a misunderstanding here. Let me explain by example:

    - Suppose user A logs in at computer C and doesn't log out.
    - User A later goes to computer D and logs in and doesn't log out there either.
    - User A comes back to computer C and he's still logged in.

    So basically he's now logged in on two different computers to the same account.

    For this scenario, would both computers have the same cookie? If that's the case, suppose someone steals user A's cookie. Does this mean that person can log in as user A anytime he wishes?

    I'm thinking the above should be true, and the cookie value is changed only when user A changes his password.

    What are your thoughts?

  8. #8
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For this scenario, would both computers have the same cookie?

    Personally, I wouldn't. I'd give each computer a seperate cookie, and match it to the user in a database.

    If that's the case, suppose someone steals user A's cookie. Does this mean that person can log in as user A anytime he wishes?

    Yes. Hence the security concerns mentioned already. Google "session hijacking." Of course, this is a concern that exists any/every time you use a cookie for sessions (including PHP's session handling functions), it's just lessened somewhat because the session is viable for a shorter period of time when you don't have "keep me logged in" functionality.

    I'm thinking the above should be true, and the cookie value is changed only when user A changes his password.

    I'd disagree - change the cookie value periodically. This would reduce (but not eliminate) the chance of someone hijacking your users' sessions.

    Really, I've never come up with a way to do this that satisfactorilly addresses the security concerns inherent in such a scheme. (Of course, some have called me paranoid, so take it as you will.) If you are set on doing this, however, here's how I'd suggest you do it:

    1) Store a session ID in a cookie with a long duration (two weeks, mayhaps). I would strongly suggest that you do not store the username in this cookie - that's just giving free information to any/all hackers! If they're going to hack you, at least make them work for it. You can refresh this cookie (reset the expiration date) with each page load. This means that if your user doesn't access the site for more than two weeks, that cookie goes away and they have to log back in.
    2) Connect this session ID to the user via a database table on each page load. Note that this means you're now handling your sessions in a database as opposed to using PHP's session management. This is what I do anyway.
    3) Using some random probability, generate a new session ID periodically (mayhaps once every 10 page loads or so). Note that you need to update the user's cookie and the database table.
    4) Require the user to confirm their identity periodically (e.g. once every 24 hours), upon which you generate a new session ID as above. Additionally, any time the user accesses important or secure information (such as account management or any admin functionality he/she has access to), require the user to again confirm his/her identity.

  9. #9
    SitePoint Evangelist ashattuc's Avatar
    Join Date
    Aug 2002
    Location
    Boise, Idaho
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some interesting thoughts. I've been wondering about this particular problem for a while. Does anyone know if the solution put forth by kromey is what vBulletin uses to store sessions?
    Chris S.

    Free Web Scripts - Form generators, AJAX tools and more!
    Micro CMS - A totally free AJAX-based, SEO-ed CMS!

  10. #10
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    368
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ok firstly the idea Oggle mentioned is bad from security perspective, i dont know of any websites that do what you propose (i.e logging into multiple machines..) or if its even possible without massive overheads

    what you should do is store the sessions in mysql's MEMORY table its fast! also use INNODB for long term storing of preferences (like number threads to display etc), this way u can do things like number of active sessions, keep track of ips, browser info, make features such as "blah, blah2 is viewing this thread"
    the above has added advantage that when ur site gets very big u can separate the database cleanly from the application and u can maintain session across multiple servers in your cluster, also when using a database you can store whole serialised objects on the server as you dont have to worry about the cookie 4KB limit ,
    also the database method has the advantage that you can use different languages such as asp.netand php while maintaining session state across them


    the only thing now u need to store in a cookie is a session_id (make this very long and random) and and authorisation id if they do login, make sure these expire withing few days (or if
    site is accessed from different ip-range exactly what gmail does), also use captchas

  11. #11
    SitePoint Member
    Join Date
    Jun 2004
    Location
    Switzerland
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBulletin stores a cookie with the userid and another cookie with the password on a users computer if he checks 'Remember Me'.

    The session itself isn't kept forever, the user is simply authenticated based on those two cookies, and then a session is created.

    Oggle, kromey, how do you imagine someone would be able to steal another persons cookie?
    Best Regards
    Colin Frei

  12. #12
    SitePoint Guru
    Join Date
    Jun 2006
    Posts
    638
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just put the user id or whatever you’re setting your session to, in a cookie.

    Then the script that checks the session should do this:
    - check session
    -- If not found, check cookie
    --- If not found, show log in
    --- If found, put cookie in session, move on
    -- If found, move on

    Really simple, guy is always logged in.
    And if you want him to always be logged in, then why you care about security? You already opened all the doors.

  13. #13
    SitePoint Wizard Nikolas's Avatar
    Join Date
    Feb 2005
    Location
    Greece
    Posts
    1,221
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the simpliest and maybe the most secure way is to give a cookie to the user which has the login/password in a encoded form (not just md5, but something that wont be easy to take back)

    Then when the user has the cookie you decode and check if the cretiria are correct.

  14. #14
    SitePoint Addict bwdow's Avatar
    Join Date
    Feb 2006
    Posts
    343
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Nikolas
    I think the simpliest and maybe the most secure way is to give a cookie to the user which has the login/password in a encoded form (not just md5, but something that wont be easy to take back)

    Then when the user has the cookie you decode and check if the cretiria are correct.
    As i know encoding requires lots of cpu usage. If your website has lots of users than your hardware may become unstable.

  15. #15
    SitePoint Addict
    Join Date
    Sep 2002
    Posts
    225
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been discussing this topic with a secutiry friend of mine at length for some time now. The best thing we could think of was to just store the user's information in a database and a cookie. In the database store the session id in one field of a table and seralize the session information in another field in the same table. Then store the session id in a cookie that lives forever. When the user returns start a new session but use the seralized information from the database if the session ids match.

    We really didn't like storing the username and password in a cookie even if it is encrypted. Doesn't seem like good practice.

    What we figure is that for private/important information we would give the user the option to have to know their password to access it to view/update that information. This way if someone does steal their session id they would still have to know the user's password to get to any of their private information.

  16. #16
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by paulsjv
    Doesn't seem like good practice.
    But you think persisting the session forever is good practice?!?

    If you are storing so much user data in the session that you have to persist it forever, I think you need to rethink that design. Sessions are for temporary persistence, not long term storage.

  17. #17
    SitePoint Guru
    Join Date
    Jun 2002
    Posts
    616
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This really depends on if you are writing your own session system or going on something that's prebuilt. That's the reason why I stay away from frameworks and so on.

    Basically I would have a cookie with a long expiry date that contains the user ID. In additional it would also contain several hashes comma separated. The hashes would be based on the ID (or some other non-changing value) joined with long, complex keys.

    I would also have a field in your user table of the database simply containing a key of random characters for each user, you could use that in combination with something else to salt an even stronger hash.

    Each time your script sees the cookie it should separate the values, validate the hashes and only then accept it as true.

    Cookies are very easy to spoof, so if you genuinely want to be secure from advanced attacks, then I would also protect sensitive areas of your website with a second login.
    Last edited by ticksoft; Sep 30, 2006 at 08:24.

  18. #18
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Colin F
    Oggle, kromey, how do you imagine someone would be able to steal another persons cookie?
    It's really quite trivial, and can happen in a couple of ways. BadGuy(R) could be sitting on the network somewhere running a packet sniffer, and he'll see every single cookie that goes across the wire, including the session cookie. Alternatively, BadGuy(R) might, through whatever means, gain access to the machine itself. Then all he has to do is read the cookie off the hard drive. There's nothing magical or secure about cookies - they are, in fact, in almost all instances holes in security, especially if they're the only criteria you use to validate a user.

    Google "session hijacking" and "packet sniffing" if you want to know more.

    Quote Originally Posted by Nikolas
    I think the simpliest and maybe the most secure way is to give a cookie to the user which has the login/password in a encoded form (not just md5, but something that wont be easy to take back)

    Then when the user has the cookie you decode and check if the cretiria are correct.
    How exactly do you see this as more secure? It is, in fact, less secure, because now instead of a session ID that you can kill off or change randomly, you have the user's username and password stored here for any/all BadGuys(R) to steal. (See above.) Sure, they might not be able to read the username/password, but that doesn't matter - they set that value in a cookie of their own, and BAM! they're now logged in as the user!! Many sites print a "Welcome, so-and-so" message, so now BadGuy(R) has the username; if you don't require the current password for password changes, or (worse yet) rely on the encoded password in the cookie, BadGuy(R) can reset the user's password, and now he's completely stolen your user's account! Or, he could just play it subtle, doing BadThings(TM) from the user's account without anyone knowing it's been hacked.

    The short answer is that persisting sessions, especially across multiple computers (i.e. allowing a user to "remember me" on more than one computer) is heinously insecure. If the system you're doing this for is just a blog or somesuch, then maybe this broad side of a barn-sized hole in your security doesn't matter.

    Ever wonder why your banks' web sites don't have a "remember me" option?

  19. #19
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ticksoft
    Each time your script sees the cookie it should separate the values, validate the hashes and only then accept it as true.
    Nice idea, but again you still only have a single cookie that needs be stolen. Far too often I see the "If I stick more than one key in the cookie, that will make it harder to steal!" solution (and I've fallen for it myself occasionally), but that's wholly inaccurate. No matter how many keys you have in your cookie, nor even how many cookies you have, it's still trivial for BadGuy(R) to grab the cookie(s) as they fly across the wire or off the hard drive and use it/them himself to gain access.

    Quote Originally Posted by ticksoft
    Cookies are very easy to spoof, so if you genuinely want to be secure from advanced attacks, then I would also protect sensitive areas of your website with a second login.
    Yes! Absolutely, 150%!!

  20. #20
    SitePoint Zealot
    Join Date
    Sep 2006
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Intresting topic. However, this is a bit off-topic but: Why would you want to be logged onto the computer forever?

  21. #21
    SitePoint Guru
    Join Date
    Jun 2002
    Posts
    616
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ChrisGilmore
    Intresting topic. However, this is a bit off-topic but: Why would you want to be logged onto the computer forever?
    Users hate to have to log in on a regular basis. They are willing to accept it for something like online banking or shopping, where security is considered paramount, but not for normal websites. It's a balance between security and convenience.

    For example, have you ever visited your favourite forum, decided to reply to a thread, clicked on the reply button and been presented by a login box? This happens to me every so often and instead of logging in, I decide that it's not really worth the hassle and instead I do something else.

  22. #22
    SitePoint Guru
    Join Date
    Jun 2002
    Posts
    616
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kromey
    Nice idea, but again you still only have a single cookie that needs be stolen. Far too often I see the "If I stick more than one key in the cookie, that will make it harder to steal!" solution (and I've fallen for it myself occasionally), but that's wholly inaccurate. No matter how many keys you have in your cookie, nor even how many cookies you have, it's still trivial for BadGuy(R) to grab the cookie(s) as they fly across the wire or off the hard drive and use it/them himself to gain access.
    Yes I understand that, at the very least it prevents the most basic of attacks where people look at the cookie and change the ID value from 1 to 2 or whatever. I have seen lots of high profile sites that simply rely on the the user ID as the cookie, and seem to assume that if it is set as a cookie then it is 100% reliable.

  23. #23
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ticksoft
    Yes I understand that, at the very least it prevents the most basic of attacks where people look at the cookie and change the ID value from 1 to 2 or whatever. I have seen lots of high profile sites that simply rely on the the user ID as the cookie, and seem to assume that if it is set as a cookie then it is 100% reliable.
    True, and I will concede that encrypted username/password values are stronger than sequential or predictable IDs. However, randomly-generated session IDs are far superior because they can be arbitrarily revoked (changed) instead of having to wait for the user to change his/her own password.

  24. #24
    Working on it... Contrid's Avatar
    Join Date
    Apr 2006
    Location
    Online
    Posts
    955
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Tell your users to get RoboForm
    And so I got lost in code...completely asphyxiated by it...

    Premium WordPress plugins - Tribulant Software

  25. #25
    SitePoint Addict
    Join Date
    Sep 2002
    Posts
    225
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape
    But you think persisting the session forever is good practice?!?

    If you are storing so much user data in the session that you have to persist it forever, I think you need to rethink that design. Sessions are for temporary persistence, not long term storage.
    Agreed...

    You really need to decide what information you are going to store in your persistant session that is in the database. When the user returns start a new session with this information, update the database with new information (session id etc), and update the user's cookie.

    Make sure to protect private information with a log in form that doesn't remember login information to force a user to at least know their password to view/update that private info.

    I think all most everyone wants (in this thread?) is a way to have a persistant login to avoid annoying things but something secure to protect users private information.


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
  •