-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep pw based auth tokens valid when pw-less login happens #27886
Keep pw based auth tokens valid when pw-less login happens #27886
Conversation
…ss login Signed-off-by: Tobias Assmann <tobias.assmann@ecsec.de>
Signed-off-by: Tobias Assmann <tobias.assmann@ecsec.de>
421392c
to
669bd4d
Compare
You unluckily need to rebase on latest master |
Signed-off-by: Tobias Assmann <tobias.assmann@ecsec.de>
…://github.com/ecsecta/server into keep_pw_based_authntoken_alive_on_pwlesslogin
@ecsecta Could you do a rebase of the branch instead of a merge with master and maybe also squash your commits into one? |
@juliushaertl The last commit should contain all changes based on the latest master. Merging this commit should be sufficient. I have no idea how to squash all commit, when not merging. If I am wrong, maybe you could point me to some docs how to do what is needed now? |
/backport to stable22 |
Thank you! |
/backport to stable22 |
1 similar comment
/backport to stable22 |
The backport to stable22 failed. Please do this backport manually. |
/backport to stable22 |
/backport to stable21 |
/backport to stable20 |
The backport to stable20 failed. Please do this backport manually. |
The backport to stable21 failed. Please do this backport manually. |
The backport to stable22 failed. Please do this backport manually. |
more luck on Friday 13th? let's fine out |
/backport to stable22 |
The backport to stable22 failed. Please do this backport manually. |
We observer token invalidations random for OpenId Connect users and early apply the fix for nextcloud#27886 Signed-off-by: Bernd.Rederlechner@t-systems.com <bernd.rederlechner@t-systems.com>
We observer token invalidations random for OpenId Connect users and early apply the fix for nextcloud#27886 Signed-off-by: Bernd.Rederlechner@t-systems.com <bernd.rederlechner@t-systems.com>
We observer token invalidations random for OpenId Connect users and early apply the fix for nextcloud#27886 Signed-off-by: Bernd.Rederlechner@t-systems.com <bernd.rederlechner@t-systems.com>
We observer token invalidations random for OpenId Connect users and early apply the fix for nextcloud#27886 Signed-off-by: Bernd.Rederlechner@t-systems.com <bernd.rederlechner@t-systems.com>
Hi,
after publishing the eID-Login app for Nextcloud users reported about the problem, that after doing a passwordless login with an eID, all already existing password based authn tokens (browser sessions and app passwords) become invalidated. See eid-login/eid-login-nextcloud#2
When investigating the issue, I found the same happens when doing a WebAuthn (password ) login. The empty password from the login is used to update existing authn tokens, which invalidates them. They get removed on the next run of
server/lib/private/User/Session.php
Line 729 in c2f62ee
To keep the existing authn tokens valid, this pull requests prevents the updating of the tokens, if the given password is an empty string.
Please note: This are the two places I found where token passwords are updated on an login attempt. I am not sure why this must happen twice? There may be more? I don`t know.
Also there is a little inconsistency in the function signatures for setting token passwords. When creating a session token a 'null' value as password can be set, which is also set it as 'null' in the database:
server/lib/private/User/Session.php
Line 679 in c2f62ee
This is resulting in different handling of the token later on:
server/lib/private/Authentication/Token/DefaultTokenProvider.php
Lines 224 to 230 in c4159e3
server/lib/private/User/Session.php
Lines 740 to 748 in c2f62ee
In these functions 'null' is not allowed but an empty string must be used:
server/lib/private/Authentication/Token/DefaultTokenProvider.php
Line 86 in c4159e3
server/lib/private/Authentication/Token/DefaultTokenProvider.php
Line 242 in c4159e3
Maybe this APIs can be changed to handle the 'null' value more consistently?
TIA for looking into this and feedback about the issue!
Greetings!