[Bug]: Passwordless authtokens should remain passwordless #30894
Comments
mdoggydog
added
0. Needs triage
…rds()` Fixes nextcloud#30894 (at least, it is supposed to). Signed-off-by: Matt Marjanovic <maddog@mir.com>
|
I just submitted a tiny PR with the fix which I mentioned at the end of my bug description above. I also forgot to mention that this issue is probably related to #26502 and its cousins (e.g., pulsejet/nextcloud-oidc-login#148). |
szaimen
added
2. developing
…rds()` Fixes nextcloud#30894 (at least, it is supposed to). Signed-off-by: Matt Marjanovic <maddog@mir.com>
|
I think I can confirm this observation:
I disabled DAV Access (not using App Passwords) to my account yesterday and I stay logged in now. |
|
I think I'm seeing something similar, it tends to happen every time my LDAP server dies for some reason. What generally happens is that the LDAP server, for some reason, starts to fail to authenticate Nextcloud. When a user logs in, this is flagged as a bad authentication by the user and all tokens are revoked. This includes SAML sessions as well as app passwords and means that users have to not only log into every single app again, but they also have to regenerate every app token. I can create a different ticket if this isn't related but it seems to be. |
It is the password of another login. But in your case this is suspicious. Is SAML the only authentication mechanism?
That smells like a bug. The token's login name should be what the user entered during login. This can, but doesn't have to be, the internal user ID. |
This comment was marked as resolved.
This comment was marked as resolved.
szaimen
added
needs info
0. Needs triage
|
I can still reproduce this problem with 25.0.3. |
joshtrichards
added
the
needs review
Bug description
On (one of) my system(s), this bug is manifesting itself in two related ways:
user_saml), after some shorter-than-usual timeout (< 1 hour), the web UI appears to have logged out and will go through the SAML auth handshake again. (Since the user still has valid credentials with the SAML IdP, this is pretty automatic, but the user will still lose any work in progress, etc.)What appears to be happening is:
PublicKeyTokenProvider::updatePasswords(). (I'm not sure what code flow is leading to this; maybe a CALDAV client logging in?)updatePasswords()scans all of the user's authtokens and updates all of them, including password-less tokens (those with anullpassword field) such that they are no longer password-less tokens.Session::getUser().Session::getUser()callsSession::validateSession().Session::validateSession()callsSession::validateToken().Session::validateToken()callsSession::checkTokenCredentials().Session::checkTokenCredentials()asks thePublicKeyTokenProviderfor the token's password (i.e.,getPassword()).Session::checkTokenCredentials()callsManager::checkPassword()to check that password!Manager::checkPassword()callsManager::checkPasswordNoLogging().Manager::checkPasswordNoLogging()ends up callingUser_LDAP::checkPassword()which callsUser_LDAP::getLDAPUserByLoginName()... which throws an exceptionNo user available for the given login name...because the$loginNamebeing provided is thelogin_namefrom the token (Nextcloud's internal user-id), not the username that a user types-in to login.Manager::checkPassword()fails, and the client fails to authenticate with its app token.It is possible that, if a system is using LDAP and is using users' public LDAP user-id's as the NC internal uid (e.g., instead of using the LDAP entry UUID as the NC internal uid) that this problem would not show itself (because
User_LDAP::checkPassword()could succeed, even though it should never have been called to begin with).However, I believe the underlying problem is that password-less app tokens are being unintentionally transformed into password-bearing tokens.
Indeed, I added a simple
if (is_null($t->getPassword())) { continue; }toPublicKeyTokenProvider::updatePasswords()and that appears to have fixed the problems that I was seeing.Steps to reproduce
See above.
Expected behavior
See above.
Installation method
Manual installation
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 22.2.3 to 22.2.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "localhost", "XXXXX.org" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "pgsql", "version": "22.2.3.0", "overwrite.cli.url": "https:\/\/XXXXX.org", "htaccess.RewriteBase": "\/", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "default_phone_region": "US", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "memcache.local": "\\OC\\Memcache\\APCu", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_smtpmode": "sendmail", "mail_sendmailmode": "smtp", "mail_domain": "***REMOVED SENSITIVE VALUE***", "ldapIgnoreNamingRules": false, "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory", "maintenance": false, "enabledPreviewProviders": [ "OC\\Preview\\PNG", "OC\\Preview\\JPEG", "OC\\Preview\\GIF", "OC\\Preview\\HEIC", "OC\\Preview\\BMP", "OC\\Preview\\XBitmap", "OC\\Preview\\MP3", "OC\\Preview\\TXT", "OC\\Preview\\MarkDown", "OC\\Preview\\OpenDocument", "OC\\Preview\\Krita", "OC\\Preview\\Movie", "OC\\Preview\\PDF", "OC\\Preview\\Postscript" ], "theme": "", "loglevel": 0, "app_install_overwrite": [ "files_texteditor" ] } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
{"reqId":"IBYIC7RBOfDmXlaHGmH3","level":0,"time":"2022-01-27T06:11:09+00:00","remoteAddr":"X.X.X.X","user":"LDAP-ENTRY-UUID-GOES-HERE","app":"user_ldap","method":"PROPFIND","url":"/remote.php/dav/files/LDAP-ENTRY-UUID-GOES-HERE/","message":"No user available for the given login name on localhost:389","userAgent":"Mozilla/5.0 (Linux) mirall/3.3.5-1 (Nextcloud, debian-5.15.0-3-amd64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"22.2.3.0","exception":{"Exception":"OCA\\User_LDAP\\Exceptions\\NotOnLDAP","Message":"No user available for the given login name on localhost:389","Code":0,"Trace":[{"file":"/srv/XXXX.org/nextcloud/apps/user_ldap/lib/User_LDAP.php","line":176,"function":"getLDAPUserByLoginName","class":"OCA\\User_LDAP\\User_LDAP","type":"->"},{"function":"checkPassword","class":"OCA\\User_LDAP\\User_LDAP","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/XXXX.org/nextcloud/apps/user_ldap/lib/User_Proxy.php","line":81,"function":"call_user_func_array"},{"file":"/srv/XXXX.org/nextcloud/apps/user_ldap/lib/Proxy.php","line":171,"function":"walkBackends","class":"OCA\\User_LDAP\\User_Proxy","type":"->"},{"file":"/srv/XXXX.org/nextcloud/apps/user_ldap/lib/User_Proxy.php","line":224,"function":"handleRequest","class":"OCA\\User_LDAP\\Proxy","type":"->"},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Manager.php","line":251,"function":"checkPassword","class":"OCA\\User_LDAP\\User_Proxy","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Manager.php","line":228,"function":"checkPasswordNoLogging","class":"OC\\User\\Manager","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Session.php","line":764,"function":"checkPassword","class":"OC\\User\\Manager","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Session.php","line":804,"function":"checkTokenCredentials","class":"OC\\User\\Session","type":"->"},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Session.php","line":268,"function":"validateToken","class":"OC\\User\\Session","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/srv/XXXX.org/nextcloud/lib/private/User/Session.php","line":243,"function":"validateSession","class":"OC\\User\\Session","type":"->"},{"file":"/srv/XXXX.org/nextcloud/apps/user_saml/appinfo/app.php","line":108,"function":"getUser","class":"OC\\User\\Session","type":"->"},{"file":"/srv/XXXX.org/nextcloud/lib/private/legacy/OC_App.php","line":303,"args":["/srv/XXXX.org/nextcloud/apps/user_saml/appinfo/app.php"],"function":"require_once"},{"file":"/srv/XXXX.org/nextcloud/lib/private/legacy/OC_App.php","line":185,"function":"requireAppFile","class":"OC_App","type":"::"},{"file":"/srv/XXXX.org/nextcloud/lib/private/legacy/OC_App.php","line":139,"function":"loadApp","class":"OC_App","type":"::"},{"file":"/srv/XXXX.org/nextcloud/remote.php","line":150,"function":"loadApps","class":"OC_App","type":"::"}],"File":"/srv/XXXX.org/nextcloud/apps/user_ldap/lib/User_LDAP.php","Line":161,"CustomMessage":"No user available for the given login name on localhost:389"}}Additional info
See above.
The text was updated successfully, but these errors were encountered: