Ticket #306 (fixed enhancement)
Switch to session based authentication
- Created: 2011-02-22 12:46:34
- Reported by: Reines
- Assigned to: Franz
- Milestone: 2.0-alpha1
- Component: authentication
- Priority: high
We should use session based authentication. Rows in the online table should correspond to active sessions, and allow 1 user to have multiple sessions.
Using a session based system is more secure for multiple reasons:
No private data is stored in the cookie.
Sessions can be invalidated server side to force log out users without changing their password.
Reines 2011-02-25 00:46:36
- Milestone changed from 2.0-beta1 to 2.0-alpha1.
Reines 2011-03-20 12:27:37
- Component set to authentication.
Reines 2011-04-06 10:28:15
- Owner set to Reines.
Reines 2011-04-08 22:40:46
I have now mostly implemented this (on top of the fluxbb-2.0-db branch). I will try tidy it up and push the changes this weekend.
Reines 2011-04-09 19:21:42
This is still a work in progress, but I've pushed the changes to a fluxbb-2.0-sessions branch, which is branched from the fluxbb-2.0-db branch.
Reines 2011-04-20 10:24:28
This is pretty much working now, though we need to make sure the session table doesn't grow too much under certain circumstances.
At the moment everyone (even guests) gets a cookie with their session ID. If no such session exists, one is created. This means, at the moment, if someone with cookies disabled (i.e. a malicious script or a search engine bot) hits 10,000 pages, we would get 10,000 sessions created. Obviously this is bad.
We can solve this by fetching the session that matches the one in the cookie, or if no match, a guest session belonging to the same IP address. That would tie guest sessions to IP addresses, but that is done at the moment anyway so should be fine.
The other situation is if a malicious user creates a script to send login requests without cookies - each login request will result in a new session for that specific user. We could solve this by setting a hard limit on how many sessions a user can have at once - though what the limit should be, and what we should do when they exceed that limit, I'm not sure. One solution would be to set the limit to 1, and that single session ID is always used for that user.
Franz 2011-12-19 15:35:15
I don't think the session limit should be one - that would make the whole session manager thing pointless
No, seriously, you should be allowed to login from different computers. I would set the limit to ten (which is reasonably large and also won't hurt us) and simply either use or throw away the oldest existing session.
Have you taken care of the issue with guests?
Franz 2011-12-21 14:44:28
I just implemented the 10 session limit. Does that look good?
Franz 2012-07-07 19:40:50
- Owner changed from Reines to Franz.
AlexCogn 2012-07-11 19:14:18
Isn't this solved with laravel?
Franz 2012-07-11 20:53:47
Almost, some things (like the online table handling) still have to be handled.
Franz 2012-08-25 22:31:02
What is still missing here?
Off the top of my head, besides debugging, these two things:
Limiting guests to one session per IP.
10-session and a lifetime limit for logged-in users.
Newman 2012-09-10 04:50:16
If your forum is secure, having private data stored in a cookie is perfectly fine.
Franz 2012-09-11 14:41:32
Newman: it's not quite that simple. Your entire site would need to be completely "safe" (whatever that means).
An XSS vulnerability somewhere on the site and off they go...
The safest cookie is one with as little private information as possible, I'd say.
Franz 2012-09-17 22:27:31
- Status changed from open to fixed.
xekon 2013-03-21 22:12:39
Franz, I had a question about this. Does this mean that if a lot of students from a college dorm were visiting my forum that only 10 of them would be able to stay logged in, and basically they would keep bumping each other logged out?
(or does it mean 10 sessions per user-id? not per IP)
Franz 2013-03-21 23:04:30
Per user ID. It would only be limited per IP for guests, which wouldn't really matter.