Fork me on GitHub
Subscribe 6

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:

  1. No private data is stored in the cookie.

  2. 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 wink

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:43:17

Commit 2f02b3d to fluxbb fluxbb-2.0-sessions

Verify that users do not have more than ten parallel sessions when logging in.

Related to #306.

Franz 2011-12-21 14:44:28

I just implemented the 10 session limit. Does that look good?

Franz 2011-12-21 14:45:46

Commit 21f2cdb to fluxbb fluxbb-2.0-sessions

Fix sort older when fetching old sessions.

Related to #306.

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-07-12 21:25:25

For reference: docs on Laravel's session database driver.

Franz 2012-08-02 22:56:49

Commit b36a10c to core sessions

#306: Create migration for sessions database table.

Franz 2012-08-03 17:14:03

Commit 4a3b96a to core sessions

#306: Create a basic session driver.

Franz 2012-08-25 10:31:59

Commit dc9c84f to core sessions

Delete the online migration. Not needed anymore.

Related to #306.

Franz 2012-08-25 10:50:20

Commit 96040ad to core master

#306: Merge feature/session.

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-11 14:43:34

Commit 4668fc1 to core master

#306: Load the FluxBB session driver in a sane way in the FluxBB bundle.

Franz 2012-09-11 15:34:32

Commit c018f08 to core master

#306: Only try to delete old sessions if there are any.

Franz 2012-09-11 15:35:38

Commit 1e36b67 to core master

#306: Bind guest sessions to IP addresses.

Franz 2012-09-17 22:11:51

Commit c726d26 to core master

#306: Make sure logged-in users have no more than ten parallel sessions.

This prunes old ones when sweeping the session (e.g. when logging in).

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)

Comment edited 1 times (Diff)

Franz 2013-03-21 23:04:30

Per user ID. It would only be limited per IP for guests, which wouldn't really matter.