RFC: Securing authentication tokens #216

New Issue

OVERLORD · 2026-02-04T17:53:35+03:00

OVERLORD commented

2026-02-04 17:53:35 +03:00

Originally created by @SimonTagne on GitHub (Aug 2, 2022).

Hello !

Here are a few thoughts about the security of authentication tokens:

The cookie is not marked as secure. If planka is served over https, the cookie should be marked secure to avoid sending the authentication token over an unencrypted connection. I think a reasonable way to check this is wether BASE_URL (or the current browser location) starts with "https".
The cookie has no SameSite attribute. Since the authentication cookie is not needed to load the front-end, it would make sense to set SameSite=Strict to mitigate CSRF.
Changing a user's password does not invalidate the token. If an authentication token is compromised (lost device, logged in on an untrusted computer, ...), there is no way to revoke a token since it only contains the user id. A solution would be to save the time of the last password change for each user in the DB, add a timestamp when generating authentication tokens and only accept tokens issued after the last password change.
The authentication token never expires. The browser will forget about the cookie after 365 days, but the token remains valid on the server indefinitely. Adding an issue or expiration timestamp in the token could solve this problem. IMHO the session duration should also be a setting rather than hard-coded to 365 days.

What do you think about that ? I would be happy to implement the measures I described above :)

Thank you for making planka !

Originally created by @SimonTagne on GitHub (Aug 2, 2022). Hello ! Here are a few thoughts about the security of authentication tokens: 1. The cookie is not marked as secure. If planka is served over https, the cookie should be marked secure to avoid sending the authentication token over an unencrypted connection. I think a reasonable way to check this is wether `BASE_URL` (or the current browser location) starts with `"https"`. 2. The cookie has no SameSite attribute. Since the authentication cookie is not needed to load the front-end, it would make sense to set SameSite=Strict to mitigate CSRF. 3. Changing a user's password does not invalidate the token. If an authentication token is compromised (lost device, logged in on an untrusted computer, ...), there is no way to revoke a token since it only contains the user id. A solution would be to save the time of the last password change for each user in the DB, add a timestamp when generating authentication tokens and only accept tokens issued after the last password change. 4. The authentication token never expires. The browser will forget about the cookie after 365 days, but the token remains valid on the server indefinitely. Adding an issue or expiration timestamp in the token could solve this problem. IMHO the session duration should also be a setting rather than hard-coded to 365 days. What do you think about that ? I would be happy to implement the measures I described above :) Thank you for making planka !

OVERLORD closed this issue

2026-02-04 17:53:38 +03:00

OVERLORD commented

2026-02-04 17:53:44 +03:00

@meltyshev commented on GitHub (Aug 3, 2022):

Hi! You are absolutely right on every point. Already looking forward to a pull request. Thank you 🙏

@meltyshev commented on GitHub (Aug 3, 2022): Hi! You are absolutely right on every point. Already looking forward to a pull request. Thank you 🙏

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#216