session timeouts



  • In an ideal system (let's say a forum that doesn't require JavaScript), how long should:

    1. a session last before it expires?
    2. a session wait before automatically renewing itself?
    3. a form's CSRF token stay valid after page load?
    4. a username have to wait after a failed login attempt before trying again?

    Additionally:

    1. how many valid sessions should a user be able to have before the oldest ones start being deleted?
    2. should this hypothetical forum have an API for use by bots?
    3. has anyone really been far as decided to use even go want to do look more like?
    4. <boomzillawtf> do they have to warn you even if the [HTTP] cookies are gluten free?

  • Discourse touched me in a no-no place

    @ben_lubar said in session timeouts:

    a session last before it expires?

    For a forum? I don't see a good reason for a session to ever expire. Let's say a year. Since the last visit.

    @ben_lubar said in session timeouts:

    a username have to wait after a failed login attempt before trying again?

    0 seconds. It's a forum, not my bank.

    @ben_lubar said in session timeouts:

    how many valid sessions should a user be able to have before the oldest ones start being deleted?

    All of them.



  • @FrostCat okay, one more question:

    1. who gets blamed when the forum has ten billion active sessions and only seven active users?


  • @FrostCat said in session timeouts:

    Let's say a year. Since the last visit.

    Year-long sessions could work, but it'd be expensive to renew the session on every page load. Maybe 6 months before the session expires it should allow it to be renewed?


  • Discourse touched me in a no-no place

    @ben_lubar You, obviously. :)

    It kind of also depends on what's in the session. Just how much is needed? Most of the stuff you could think of, mainly customizations or a list of read topics or whatever, has no business there.


  • Discourse touched me in a no-no place

    @ben_lubar said in session timeouts:

    Year-long sessions could work, but it'd be expensive to renew the session on every page load.

    That seems rather superfluous, yes. I don't see any reason OTTOMH 6 months wait isn't a reasonable starting point. I'm not sure why extending the session necessarily needs to be expensive, but I don't feel like arguing about it or getting down deep into the weeds.



  • People are seriously suggesting that sessions should stick around for hours at a time? You're wasting a lot of disk space and/or server memory if you do that.

    Personally, I'd keep them for no longer than a day... no longer than an hour on a busier site.

    Having said that, that's assuming there's some JavaScript to call a web service or something to auto-renew the session if someone leaves it running in a tab.

    (Not that that will help you in Chrome since it likes to unload tabs if you haven't looked at them in a while.)



  • @ben_lubar said in session timeouts:

    a session last before it expires?

    Use a session cookie in the browser; let it decide.

    EDIT: wait, what kind of session are we talking about and what kind of expiration do you mean? I wouldn't want to have to log in again for at least 2 weeks at a time.

    @ben_lubar said in session timeouts:

    a session wait before automatically renewing itself?

    Hm.

    I don't know.

    @ben_lubar said in session timeouts:

    a form's CSRF token stay valid after page load?

    I'd say at least a half-hour.

    @ben_lubar said in session timeouts:

    a username have to wait after a failed login attempt before trying again?

    Make it take 0.5 seconds longer each time. (So you wait a half second, then a second and a half, then two seconds, etc.)

    @ben_lubar said in session timeouts:

    how many valid sessions should a user be able to have before the oldest ones start being deleted?

    Why limit it at all?

    @ben_lubar said in session timeouts:

    should this hypothetical forum have an API for use by bots?

    Only if it is non-functional.

    @ben_lubar said in session timeouts:

    has anyone really been far as decided to use even go want to do look more like?

    Pricipal . Caught sayof school that has stoped Handstandsing " See, told ya so" Is He dead or not. CNN Says yes. Tampa Bay Times Looking for chads -OR- "hello, I am write single to salute and wait for answer again"



  • I agree with frostcat's answers, plus

    1. a form's CSRF token stay valid after page load?

    At least a couple hours, so that one can write a fully-researched-and-crosschecked post without having to resort to notepad. A day?

    1. should this hypothetical forum have an API for use by bots?

    Now that botmania has died down, the few that are floating around seem to be useful, like the mafia bot.

    1. <boomzillawtf> do they have to warn you even if the [HTTP] cookies are gluten free?

    They should warn me especially if the cookies are gluten-free. :donotwant.pcx:


  • Discourse touched me in a no-no place

    @powerlord said in session timeouts:

    Personally, I'd keep them for no longer than a day... no longer than an hour on a busier site.

    So every time I don't visit in a day or so I have to log back in like an animal? Ugh.

    Disk is cheap. Throw another few rows in the session table.



  • @FrostCat said in session timeouts:

    @powerlord said in session timeouts:

    Personally, I'd keep them for no longer than a day... no longer than an hour on a busier site.

    So every time I don't visit in a day or so I have to log back in like an animal? Ugh.

    Disk is cheap. Throw another few rows in the session table.

    It's a pretty common tactic for the actual server sessions to be decoupled from the Remember my login "session." There's also the issue where larger sites may use something like memcached to share its sessions across multiple app servers.



  • @reverendryan said in session timeouts:

    1. a form's CSRF token stay valid after page load?

    At least a couple hours, so that one can write a fully-researched-and-crosschecked post without having to resort to notepad. A day?

    It's not like the forum would eat your post. You'd just get a "sorry, that form was old. submit it again." with your content still in the box.



  • @FrostCat said in session timeouts:

    @ben_lubar said in session timeouts:

    a username have to wait after a failed login attempt before trying again?

    0 seconds. It's a forum, not my bank.

    Given the typical lack of password security for the average user, you can't let an attacker brute force passwords on a forum any more than on a bank site. Because the average user is going to have the same credentials on both sites.

    I'll grant that on this forum, it's not unreasonable to assume that the overwhelming majority of users have avoided that security pitfall, but since Ben's questions were toward a hypothetical ideal system, I would advocate for a standard escalating lockout on failed password attempts (maybe with a ~3 try grace period before it phases in).



  • @blakeyrat said in session timeouts:

    hello, I am write single to salute and wait for answer again

    @blakeyrat,
    My sister and me think you are so cool.
    Do you have a girlfriend? There is two of us.
    Yours,
    @fbmac



  • @ben_lubar said in session timeouts:

    1. a session last before it expires?

    Which session? As @powerlord said, the login session is often decoupled from other session info.

    I would say: Use a cookie, let the browser store it as long as it likes. Re-validate access rights periodically for performance or on every request for security.

    1. a session wait before automatically renewing itself?

    What does "renewing" mean in this context?

    1. a form's CSRF token stay valid after page load?

    Somewhere close to forever. What's the reason for expiring it?

    1. a username have to wait after a failed login attempt before trying again?

    One second, increasing exponentially on each failure. Or just one second every time.

    1. how many valid sessions should a user be able to have before the oldest ones start being deleted?

    As many as the cookies they can manage.

    1. should this hypothetical forum have an API for use by bots?

    Why not? Bots can be fun.

    1. has anyone really been far as decided to use even go want to do look more like?

    ...

    1. <boomzillawtf> do they have to warn you even if the [HTTP] cookies are gluten free?

    I'm gluten-free intolerant, shitlord! TRIGGERED!



  • @ben_lubar said in session timeouts:

    In an ideal system (let's say a forum that doesn't require JavaScript), how long should:

    1. a session last before it expires?

    A year.

    1. a session wait before automatically renewing itself?

    Six months.

    1. a form's CSRF token stay valid after page load?

    What kind of token? And how long is it? It should stay valid for 200ms * 2(len token). Or until you see it used.

    1. a username have to wait after a failed login attempt before trying again?

    zero seconds, zero seconds, zero seconds, five seconds.

    Additionally:

    1. how many valid sessions should a user be able to have before the oldest ones start being deleted?

    10

    1. should this hypothetical forum have an API for use by bots?

    Yes

    1. has anyone really been far as decided to use even go want to do look more like?

    Void.

    1. <boomzillawtf> do they have to warn you even if the [HTTP] cookies are gluten free?

    No.



  • @another_sam said in session timeouts:

    @ben_lubar said in session timeouts:

    1. a session last before it expires?

    Which session? As @powerlord said, the login session is often decoupled from other session info.

    Right now, the cookie is an encrypted, signed struct containing a 32 byte CSRF token encryption key, a timestamp for when the cookie expires (so it can be renewed before then) and a database session ID. Non-logged-in users have the first two fields, logged-in users have all three.

    @another_sam said in session timeouts:

    I would say: Use a cookie, let the browser store it as long as it likes. Re-validate access rights periodically for performance or on every request for security.

    If you don't tell the browser how long to store the cookie, it deletes it whenever the "session" expires, which means whatever the browser wants it to.

    @another_sam said in session timeouts:

    1. a session wait before automatically renewing itself?

    What does "renewing" mean in this context?

    For non-logged-in users, renewing the session is simply re-sending the cookie with a later expiration. For logged-in users, the database entry for the session has to be updated, which means a database write. The server needs to know about the sessions so users can remotely kill them.

    @another_sam said in session timeouts:

    1. a form's CSRF token stay valid after page load?

    Somewhere close to forever. What's the reason for expiring it?

    The idea is that if that token somehow gets seen by a malicious third party (such as when the user copies an entire forum page into their post), the user cannot be CSRF'd into doing arbitrary things.

    Currently, my code generates a CSRF token by encrypting a timestamp with some crypto random bytes that are stored in the session cookie.

    @another_sam said in session timeouts:

    1. how many valid sessions should a user be able to have before the oldest ones start being deleted?

    As many as the cookies they can manage.

    A user only has one session per browser instance, but if they repeatedly clear their cookies and log back in, they'll fill up the database. I'm not saying we should limit the user to 3 sessions. I'm saying we should prevent DOSing via login sessions.



  • @ben_lubar said in session timeouts:

    I'm saying we should prevent DOSing via login sessions.

    This sounds like the kind of thing that might need to be configurable/extendable.

    How about 1.5*(the largest number of simultaneous sessions with a real use case)?

    I'm having a hard time imagining that could possibly be bigger than 50. Someone who goes incognito on the forums a lot + they do this in Chrome, firefox, iceweasel, opera, vivaldi, edge, and IE6/9/10 on their work machine, their personal laptop, and their work laptop + their old work laptop sessions will still have 'only' 27 actual sessions someone cares about or would even be able to tell if they were invalidated.

    If you keep the newest session from each browser(whitelist major ones, others get pitched into a single 'browser' misc/unknown. No working around it with user-agent spoofing) and forget old ones if you have more than 50, I'm having trouble imagining a use case where that would be problematic. Even a web developer who runs a lot of browsers and clears their cookies a great deal will still be able to open up iceweasel for the first time in three months and have their session still work. Why are the forums open in all their browsers? Who knows.

    If they clear their cookies or visit incognito mode/equivalent a lot that can invalidate sessions on the browser they visit the forums on if they have it minimized somewhere. If you can type your username and password to login in incognito or whatever 40 times, you can't be that irritated at having to re-login when you turn cookies back on. And if you are I officially don't care about your complaining.



  • @ben_lubar Right now, the cookie is an encrypted, signed struct containing a 32 byte CSRF token encryption key

    Double submit cookie validation one can assume then? Using Session ID as your nonce?



  • @izzion said in session timeouts:

    I'll grant that on this forum, it's not unreasonable to assume that the overwhelming majority of users have avoided that security pitfall

    fuck....

    fuck fuck fuck fuck fuck.

    Ben.... we have a problem.



  • @ben_lubar said in session timeouts:

    A user only has one session per browser instance, but if they repeatedly clear their cookies and log back in, they'll fill up the database. I'm not saying we should limit the user to 3 sessions. I'm saying we should prevent DOSing via login sessions.

    Have it expire after, say, a reasonable amount of inactivity. Say, a month. As long as there's still activity, it should last indefinitely.

    Anything which isn't the current system of expiring sessions seemingly arbitrarily.


  • Discourse touched me in a no-no place

    @ben_lubar said in session timeouts:

    a username have to wait after a failed login attempt before trying again?

    On the order of seconds. It's a DOS (on the account owner) waiting to happen otherwise.


  • Winner of the 2016 Presidential Election

    @ben_lubar said in session timeouts:

    a session last before it expires?

    A few weeks.

    @ben_lubar said in session timeouts:

    a form's CSRF token stay valid after page load?

    As long as the session is valid and you don't navigate to another page. Make sure you get an up-to-date CSRF token if the user uses the back button.

    @ben_lubar said in session timeouts:

    a username have to wait after a failed login attempt before trying again?

    0 seconds if it's one of the first 10 attempts. Then increase the time exponentially.


  • Winner of the 2016 Presidential Election

    @PJH said in session timeouts:

    On the order of seconds. It's a DOS (on the account owner) waiting to happen otherwise.

    Obviously, only the same IP should be delayed on further attempts. You have to do something against brute-force attacks.


  • mod

    @asdf said in session timeouts:

    . Then increase the time exponentially.

    so 0^1, then 0^2, then 0^3, then a whopping 0^4?


  • Winner of the 2016 Presidential Election

    @Yamikuronue I'd love to flag this for pedantry.


  • Discourse touched me in a no-no place

    @asdf said in session timeouts:

    Obviously, only the same IP should be delayed on further attempts. You have to do something against brute-force attacks.

    Then it becomes a problem in preventing DDOS against the site without incurring a DOS against the user.

    Which still places it in the 'order of seconds' suggestion earlier.



  • @ben_lubar said in session timeouts:

    It's not like the forum would eat your post. You'd just get a "sorry, that form was old. submit it again." with your content still in the box.

    That's a really shitty user experience.

    Not that you'd care, you're all open source-y.



  • @ben_lubar said in session timeouts:

    If you don't tell the browser how long to store the cookie, it deletes it whenever the "session" expires, which means whatever the browser wants it to.

    That's the correct thing to do because it ensures the session is active as long as the browser window is open.



  • There are forums I've been logged into for years and have never had to re-log into. That's how it should work.



  • @ben_lubar said in session timeouts:

    I'm saying we should prevent DOSing via login sessions.

    Who gives a shit? We're letting DailyWTF users DoS other sites by them accidentally typing text after pasting a one-post-able link. Let's remove that stink from this broken shitty site before we worry about strange hypothetical problems.



  • @blakeyrat said in session timeouts:

    That's a really shitty user experience.

    Ohhh noooooo. I spent two days composing an exhaustively researched giant megapost. Now I have to push two buttons! Instead of one button!

    And I can't be CSRF'd via brute force!


  • Winner of the 2016 Presidential Election

    @AyGeePlus It doesn't make the forum unusable, but it's still a shitty user experience. Blakey is absolutely right there.



    1. A week or so. Re-auth for important actions.

    2. ? Renew on every request.

    3. 6 hours or so? Time isn't really the issue with CSRF

    4. Logarithmic. Something like 3x^(2/3)

    5. 3-5

    6. Maybe? Do you want bots?

    7. You've got to be kidding me. I've been further even more decided to use even go need to do look more as anyone can.

    8. No

    Feel free to critizise



  • @JazzyJosh said in session timeouts:

    Logarithmic. Something like 3x^(2/3)

    That's not logarithmic.



  • @AyGeePlus said in session timeouts:

    What kind of token? And how long is it? It should stay valid for 200ms * 2(len token). Or until you see it used.


  • sockdevs

    @ben_lubar said in session timeouts:

    @JazzyJosh said in session timeouts:

    Logarithmic. Something like 3x^(2/3)

    That's not logarithmic.

    Maybe not, but it kinda looks a bit like it: http://www.wolframalpha.com/input/?i=graph+of+3x^(2%2F3)


  • Winner of the 2016 Presidential Election

    @JazzyJosh said in session timeouts:

    Time isn't really the issue with CSRF

    ^ This. The point of a CSRF token is that it's

    • Not stored in a cookie.
    • Not predictable.
    • Changes every time a form is submitted, so that brute-force attacks are also basically impossible.

    It doesn't have to expire at all if the user doesn't perform an action in that browser session.



  • @asdf the thing is, you need some way of verifying that the CSRF token is real.

    For that, you need to store something in the user's session that can verify the CSRF token. I guess you could also store each randomly generated token in the database, but that's gonna get huge after bots index your login page a few thousand times.

    The way I'm doing it is having a timestamp that gets signed and encrypted with a random 32 byte key associated with the session. The CSRF token is valid if the timestamp is before now and after [some duration] ago and the signature is valid.



  • @ben_lubar log(x) too low. Exponential can cause problems for actual users, i.e. Fuck now I need to wait 4 minutes to try again. FUCK NOW I NEED TO WAIT 8 MINUTES.



  • @JazzyJosh just have it cap at a certain point and require either admin intervention or a long constant amount of time.



  • @ben_lubar Make it 3 days. If you're posting 3 days after visiting the thread, there's probably something you missed in the interim.



  • @JazzyJosh The bigger problem on web forms is that 99% of the time the delay is enforced on the back-end but the front-end doesn't correspondingly grey-out the login button. So there's no UI feedback that the delay is in-effect.


  • Winner of the 2016 Presidential Election

    @ben_lubar said in session timeouts:

    For that, you need to store something in the user's session that can verify the CSRF token.

    So basically, we're at "how long do I keep the session" again, then.

    @ben_lubar said in session timeouts:

    The way I'm doing it is having a timestamp that gets signed and encrypted with a random 32 byte key associated with the session. The CSRF token is valid if the timestamp is before now and after [some duration] ago and the signature is valid.

    Sounds a bit complicated.



  • @asdf said in session timeouts:

    Sounds a bit complicated.

    The only less complicated way I can think of is storing the CSRF token somewhere in a database. And that gets ugly fast because visiting the login page needs to generate a CSRF token.


  • Winner of the 2016 Presidential Election

    @ben_lubar said in session timeouts:

    And that gets ugly fast because visiting the login page needs to generate a CSRF token.

    Wait, why? What can a malicious third-party website do if you're not even logged in? CSRF tokens are only necessary once the user is logged in.



  • @asdf said in session timeouts:

    @ben_lubar said in session timeouts:

    And that gets ugly fast because visiting the login page needs to generate a CSRF token.

    Wait, why? What can a malicious third-party website do if you're not even logged in? CSRF tokens are only necessary once the user is logged in.

    a malicious third party can log you into an account.


  • Winner of the 2016 Presidential Election

    @ben_lubar said in session timeouts:

    a malicious third party can log you into an account.

    Hm, I actually never thought of that. But that doesn't sound too bad as long as your application makes it easy to figure out which user you're logged in as.



  • @ben_lubar You know, Ben L, you could just adopt WebForms, which does all the CSRF stuff automagically and you never have to think about it.



  • @blakeyrat said in session timeouts:

    @ben_lubar You know, Ben L, you could just adopt WebForms, which does all the CSRF stuff automagically and you never have to think about it.

    I'd rather give the user the ability to resubmit the form than give them a generic "BAD THINGS HAPPENED" page that doesn't even ask my application how to render it.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.