Password set via login fails to take effect until restart

[Vance-Turner]

Jupyter notebook passwords set via the login interface seem to not take effect until the jupyter process is restarted. Such behavior seems contrary to what is stated here:

Next time you need to log in you’ll be able to use the new password instead of the login token, otherwise follow the procedure to set a password from the command line.

The issue can be reproduced by:

1. jupyter notebook --NotebookApp.allow_password_change=True --NotebookApp.token=sillytoken
2. Open up localhost:8888 (without the token in the URL)
3. Change password via the token
4. Log out
5. Return to log in page and attempt to use password set. Notebook refuses password.
6. Shutdown jupyter from terminal.
7. Start jupyter again and attempt to log in. Password set earlier is accepted.

Is there some configuration I am missing to have passwords immediately take effect? Such behavior is desirable as we are trying to use JupyterLab within a docker container, but users' passwords do not take effect until the process is restarted which in the context of docker implies the container is destroyed. The behavior present in the docker stack seems to arise from Jupyter itself.

[domschl]

This is still not fixed with jupyterlab 0.35.5.

A restart of the server is required in order to change the password. Since this is not indicated to the user, the default assumption of users might be that password-setting does not work at all:

1. Set password on freshly installed server with token
2. login works ok (only once!)
3. Go to remote computer: login fails.

This behaviour is inconsistent, because the first login with password-setting and token seems to have worked fine. It just works once until the server is restarted.

Since this might lead to users disabling authentication, this bug is security relevant. At the very least, it should be signalled to the user that a restart of the server is required, if a user changed the password...

[emin63]

I was recently bitten by this issue. I think possibly even a restart may not be enough. I believe I had a cookie generated from a token and even after restarting the server and changing the password, I was able to login without being challenged for the password.

From a brief glance at the code, it seems like the server is generating some kind of secret and using that to sign cookies. That secret seems to persist after server restarts. (See also #2562 which mentions this issue). So if someone has a signed cookie, they can keep using that signed cookie to keep logging in unchallenged even after a password change and server restart.

If the above hypothesis is accurate, I think the server should generate a new secret after restart. There is still the issue that you need a restart for the password change to take effect. But without the restart you have the problem that an attacker who gets a valid signed cookie can keep using that even after a password change. This issue is why there is the refresh token and access token combination for JWTs.

Apologies if I misunderstand what is going on above and the above suggestion is not helpful. The basic point is that it seems like the secret used for signing/validating cookies persists even after restarts which allows someone who obtained a valid cookie to keep using it even after password change and server restart.

Finally, thanks for all your work on jupyter. It's amazing software.