Why does SMF log out on all browsers/devices?

[Kolya]

When logging out of an SMF 2.x forum you get logged out on all browsers/devices. I assume that any session associated with that user ID is dropped at that point.
But I wonder what is the reason for this?
It might easily happen that I leave my PC at work and hence log out there, but still want to be able to check the forum on my mobile device or my laptop at home. Then I have to login all these browsers individually again.

[Kindred]

something that you have done has changed the default code, since that does not happen on a standard installation
(for example, I logged out of this forum at work, but I as still logged on on my phone, my iPad and my home computer)

So - if you are seeing something different, then your system has been changed to act differently.

[Arantor]

Happens here to me consistently, logging out on desktop will log me out on all other devices.

This is intentional but I forget exactly why this is so.

[margarett]

Me too. It's extremely rare that I log out but when I do, all my logins go caput

[Kindred]

hmmm... wonder why it does not happen to me?

[Steve]

Because you're special?

[Arantor]

hmmm... wonder why it does not happen to me?

Do you explicitly log out or set the session to time out after, say, an hour when at work?

[Kindred]

I actually log out... I think.

Maybe I am just killing all my cookies.  hrm....   have to do some testing

[Arantor]

Yup, you nuking your local cookies is not the same as logging out.

[Kolya]

So does anyone know why this happens?
I didn't see anything obvious in LoginOut.php. I mean, it does delete the user from the log_online table without checking for other sessions. But I think log_online is just for presentation, isn't it?

[Arantor]

As I said, I know the cause in the code for this. I just don't remember why the code operates this way - but I also know it was done this way for a very good reason. I'm just extremely hesitant to give out changes to this stuff because done wrong this can break every ounce of security on your site. I'm sure you understand my hesitation.

The worst part is that I know who changed it, I know when it was changed. I know this because it would appear to have been me. If I were to guess - bearing in mind we're talking about a security report over a year ago at this point in time - I would have to say it was a discovered session fixation bug. But I don't have access to the reports and don't remember the proof of concept. I just remember that intentionally forcing sessions to be force rebuilt after a logout was the most secure of the choices on offer at the time.

However I can also note it was not intended to kill all sessions, only prevent the now-expired session from being reused.

[Kolya]

Of course it would be nice if you could find a way to prevent this in future. For now I just wanted to know why it works that way and you answered that question.
Maybe you could add this to the bugtracker? Apparently I don't have the required permission.

[Arantor]

Re using the bugtracker... 2.0 isn't getting any major bug fixes and in any case Mantis is deprecated; anything that's going to be fixed would typically be fixed in 2.1 first (for which Github is the proper venue, not here), but the same code should be in 2.1 for the same reason, and I don't see how it can be changed without making it less secure, sorry.

The entire point of the code is about ensuring a session can't be used after it has been ended, which requires forcing the session to be killed - and part of doing that requires forcing it on the account itself.

[Kolya]

I'm probably out of my depth here, so just take this as curiosity: Apparently SMF can deal with multiple sessions on the same account. So why do all sessions have to be destroyed to prevent one session from being reused?

[Arantor]

Because there is only one way you can actually make *sure* that's the case. There is a kind of secondary token that gets implanted into each session, which can't be supplied by the client side except by brute force because it's never sent outside the server (and then hashed into the session token)

The only way to absolutely guarantee a session can't be reused is to destroy and recreate that token, which is what the code does on logout. Anything else is subject to tampering.

[Kolya]

And creating a different token for each session is no option?

[Arantor]

Given how it's created, it's not an option, no. But if you think you understand what is happening, be my guest to try it.