Usability and CSRF tokens

Question

In a lot of different products the CSRF token is stored in a session.

Which means that if the session has expired then the next form submit will fail.

Example scenario: you open a login form, the session is implicitly created if you didn't have one yet and a CSRF token is persisted in a session and is put as a hidden field of a form.

Then you wait until the session is expired (and garbage collected), then you fill your credentials and submit it.

Now even if the credentials are correct you will see the ugly "CSRF token is invalid" (or something similar) form validation error message.

So the question is: is there a secure way to improve this flow?

PS: ... apart of using AJAX to periodically poll some endpoint to keep the session alive.

Answer 1

(this question might be better suited for the User Experience site)

Change the error message to "We need you to log in again because you were inactive for more than XX minutes." Problem solved.

Let the user know how long they have exactly, because if they have to submit a complex form they need to be aware that they will need to collect whatever information they need and prepare whatever text they must input within a set time. Even better, monitor on which forms sessions tend to reset and use that information to figure out if you must support longer-lasting sessions.

Sometimes users might make a token expire before they even logged in as you pointed out. In that case, a formulation that is generic enough to cover both use cases will remove the need for you to try and test how the session looked like before it expired. You still need to address the confusion that such a message can cause for users who were not logged in before (their mental model might not accommodate the idea that individual forms expire rather than actual sessions).

You can do so by adding a "learn more" or "more details" link on your error message. Clicking that link can then display an additional paragraph that explains (succintly, and in very simple prose!) that Web login forms expire after XX minutes for security reasons, and the user was inactive for too long. You'll still need to ensure that additional text is visible to users without JS.

At this point you might as well implement your idea of serving a fresh CSRF token via AJAX when the user has been inactive for long enough...

---

Edit: some services directly display a timer indicating for how long the current page will be valid. You could go as far as implement such a timer on a standalone login page. This will at least prepare users to the idea that the page has expired / will expire, and can be especially useful if the page must be entirely refreshed when the timer expires. This being said, thee proper approach remains to never invalidate the existing login page.

Answer 2

There's always been a trade between UI and security. To my knowledge, CSRF Tokens at login page is to protect against brute-force attack, which might also be achieved by other means like Captcha verification. It may also be abused, if possible, to make victims login to attacker's account and do some nasty stuff, but that's rare, I guess.

The best, I think, is to refresh the token with new one automatically as soon as it gets expired. Implementing plain CSRF Token that remains static throughout a period of time is of no use at all.