Expire authentication token upon app restart

[MarcS1975]

I logged into an existing Flatnotes application using my password. All fine and all my docs were shown.
Then I noteiced that restarting the container keeps me logged into the website. This shuld not happen.
Even deleting the container and the docker image and re-installing an updated Faltnotes image does not require me to log in again.
I think these are major security risks. Any change of the underlying system should autmooatically kick the user out and force re-login.

[dullage]

Hi @MarcS1975. I don't agree that this is a security risk. Why should a restart of the container be related to invalidating user sessions? Maybe you just restarted the server for maintenance. Surely you wouldn't want this to kick you out?

What's happening under the hood is that the login process generates a token. This token is only invalidated by the following events:

1. The token expires. This is controlled by the FLATNOTES_SESSION_EXPIRY_DAYS environment variable, which defaults to 30 days.
2. The secret used to generate the token is changed. This is controlled by the FLATNOTES_SECRET_KEY environment variable.

So if you want to invalidate all existing sessions, simply update the secret key.

I hope this helps.

[MarcS1975]

I have not just restarted. I have stopped the container, removed it, removed the imaged, pulled a new (updated) image and restarted a totally new container from a new image. There is no way a token should still be valid on an entirely new application.

…

On Wed, 16 Oct 2024, 17:08 Adam Dullage, ***@***.***> wrote: Hi @MarcS1975 <https://github.com/MarcS1975>. I don't agree that this is a security risk. Why should a restart of the container be related to invalidating user sessions? Maybe you just restarted the server for maintenance. Surely you wouldn't want this to kick you out? What's happening under the hood is that the login process generates a token. This token is only invalidated by the following events: 1. The token expires. This is controlled by the FLATNOTES_SESSION_EXPIRY_DAYS environment variable, which defaults to 30 days. 2. The secret used to generate the token is changed. This is controlled by the FLATNOTES_SECRET_KEY environment variable. So if you want to invalidate all existing sessions, simply update the secret key. I hope this helps. — Reply to this email directly, view it on GitHub <#250 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMNNHGXGDAVNFHGG53VZ4GLZ32FRHAVCNFSM6AAAAABQBSS2V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJXGI4DCOJUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MarcS1975]

A token should expire on the following events: 1) time limit 2) code changes on the underlying code 3) code changes on the browser side (new chrome version) Those are just a few events. If you ask a security community they will probably have a few more events.

…

On Thu, 17 Oct 2024, 09:51 M S, ***@***.***> wrote: I have not just restarted. I have stopped the container, removed it, removed the imaged, pulled a new (updated) image and restarted a totally new container from a new image. There is no way a token should still be valid on an entirely new application. On Wed, 16 Oct 2024, 17:08 Adam Dullage, ***@***.***> wrote: > Hi @MarcS1975 <https://github.com/MarcS1975>. I don't agree that this is > a security risk. Why should a restart of the container be related to > invalidating user sessions? Maybe you just restarted the server for > maintenance. Surely you wouldn't want this to kick you out? > > What's happening under the hood is that the login process generates a > token. This token is only invalidated by the following events: > > 1. The token expires. This is controlled by the > FLATNOTES_SESSION_EXPIRY_DAYS environment variable, which defaults to > 30 days. > 2. The secret used to generate the token is changed. This is > controlled by the FLATNOTES_SECRET_KEY environment variable. > > So if you want to invalidate all existing sessions, simply update the > secret key. > > I hope this helps. > > — > Reply to this email directly, view it on GitHub > <#250 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMNNHGXGDAVNFHGG53VZ4GLZ32FRHAVCNFSM6AAAAABQBSS2V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJXGI4DCOJUHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[dullage]

I understand that invalidating the token in these scenarios would, in some cases, enhance security. I'm sure there are many other things that could be done to enhance security. But I still don't agree that not doing so is a "major security risk".

[MarcS1975]

Do you run your server with SSL directly exposed to the internet?