session timeouts
-
@blakeyrat said in session timeouts:
@ben_lubar You don't really need a user-friendly error message on a CSRF problem because the only way that can happen (assuming your CSRF tokens are tied to browser session) is via. Haxxy Mc Haxalot.
except that you have proven that is not true:
-
@ben_lubar Read what I typed again:
assuming your CSRF tokens are tied to browser session
NodeBB is obviously doing this (as it does so many millions of other things) wrong and stupid and incorrect and buggy.
-
@ben_lubar If it can recognize that you have to resubmit, and then lets you do so, then it can resubmit for you.
-
@xaade said in session timeouts:
then it can resubmit for you.
Isn't the entire point of CSRF to not automatically resubmit?
-
If you can immediately manually resubmit, then why can't it automatically resubmit?
If there's a problem with the session, kick the user out. If not, resubmit
-
@JazzyJosh I mean is it an encrypted whatsit or a cryptographic signature or a header-matches-cookies deal or what. There's more than one way to skin a cat.
-
@AyGeePlus it's 15 bytes of timestamp and a SHA256-HMAC signature of the timestamp. That gets encrypted and then base64 encoded.
-
@ben_lubar Yeah, you answered above, I think.
-
@xaade said in session timeouts:
If you can immediately manually resubmit, then why can't it automatically resubmit?
Because the whole point of a CSRF protection mechanism is to make sure that the user manually invoked an action after voluntarily visiting a certain page. Anything a browser can be tricked into doing automatically by a third-party website is vulnerable to CSRF attacks.
-
@asdf said in session timeouts:
@xaade said in session timeouts:
If you can immediately manually resubmit, then why can't it automatically resubmit?
Because the whole point of a CSRF protection mechanism is to make sure that the user manually invoked an action after voluntarily visiting a certain page. Anything a browser can be tricked into doing automatically by a third-party website is vulnerable to CSRF attacks.
Not to mention a design constraint on this nonsense is Javascript-free.
-
@asdf said in session timeouts:
As long as the session is valid and you don't navigate to another page
Why do you hate tabbed browsing? You're a terrible person.
-
@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.
The browser (or user) can delete the cookies whenever it wants to anyway.
But I was not clear. I meant for you to set a long expiry, possibly even forever, and let the user and/or browser manage the cookie's lifetime. It's a web forum, not access to banking or anything else of value.
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.
I assume you're checking something on the server with every renewal, otherwise why are you renewing instead of never expiring? What are you updating in the session database entry?
The server needs to know about the sessions so users can remotely kill them.
That requirement can be implemented with a "last-valid-session" timestamp or something similar on the user record.
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.
So a form was presented to the user but they didn't submit it, and the token for that form, which is only visible in source, somehow managed to become comporomised? I'm not convinced this is a likely scenario. If you're concerned, maybe a day or a week is an appropriate expiry? It should be quite long.
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.
You haven't demonstrated any requirement for server-side session storage yet.
-
@blakeyrat said in session timeouts:
That's a really shitty user experience.
Please describe an alternative experience that is superior.
Not that you'd care, you're all open source-y.
http://allthingsnext.com/wp-content/uploads/2010/12/Beat_Dead_Horse.jpg
-
@ben_lubar said in session timeouts:
In an ideal system (let's say a forum that doesn't require JavaScript), how long should:
- a session last before it expires?
A quarter of the expected time to brute force the secret token.
- a session wait before automatically renewing itself?
Why is this even a thing? Let them log back in at the end of 32.4 years or whatever.
- a form's CSRF token stay valid after page load?
Half the expected time to brute force the secret token.
- a username have to wait after a failed login attempt before trying again?
One second.
Additionally:
- how many valid sessions should a user be able to have before the oldest ones start being deleted?
Unbounded.
- should this hypothetical forum have an API for use by bots?
Yes.
- has anyone really been far as decided to use even go want to do look more like?
Wut.
- <boomzillawtf> do they have to warn you even if the [HTTP] cookies are gluten free?
Wut.
