App-Token/App-Password invalidates after some time (probably Android-App fault)

Hi,

I had a couple of incidences where the app-token/app-password fails.

Latest incident: The server was down for 3 days.

setup:

  • NC 27.1.4
  • 2FA for my user
  • seperate App-Tokens for all clients that need one (see below)
  • NC-desktop-app 3.10.1 (Arch)
  • NC-android-app 3.26.0

Symptoms after the reboot of the server:

  • the app-token for the NC-Desktop-Client fails
  • the app-token for the NC-Android-Appclient fails
  • the app-token for the Thunderbird-Calendar fails
  • the app-token for a webdav-mount works fine
  • the app-token for the Android-Dav5x works fine

I am at loss. The problem comes if I have to enforce users to use 2FA and the app-tokens start to fail for some unknown reasons.

Anyone an idea how to debug this?

  • Can I check the “validity” of an app-password in the database?
  • Can I debug the process on the client side (NC-Desktopclient maybe)?
  • Is it rather on the server-side (since Thunderbird is seeing the problem too?)

Greetings

Anyone the same behaviour?

A day later the app-token for the Android-Dav5x fails to work, so it might not have something to do with reboot or server outages.
It might just be a random thing or a time-based thing.

Is there such a thing as “app-tokens get invalidated after a configured time”?

Cheers for any comment.

What do your server-side logs indicate when the various clients attempt to use these apparently no-longer-functioning app passwords?

Might be worth bumping your loglevel down to get more details temporarily too.

1 Like

Only with loglevel = 0:

Dav5x:

No public access to this resource., Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, Username or password was incorrect

The Nextcloud-App on Android:

Token is not valid: Token is too short for a generated token, should be the password during basic auth

and

"exception":{},"CustomMessage":"Exception thrown: OCA\\DAV\\Connector\\Sabre\\Exception\\PasswordLoginForbidden

That just seems as if the apps forgot their passwords.

Ok. Update:

  • I had the high-performance-backend (notify_push) configured, though probably not correctly (push server is not a trusted proxy · Issue #11 · nextcloud/notify_push · GitHub)
  • I will leave the notify_push backend online, since I figure that only the desktop app and probably not the android app (can’t see anything in the logs that it does) use the notify_push backend, while all my other services seem to invalidate their app-tokens

bumping up the thread.

It is still happening to me:

  • I detangled the admin-account from the user-account to make sure that the account that it is happening to is not special
  • for no apparent changes the app-passwords dropped out of being valid one by one: NC-app on android, then Dav5x-app on android, then caldav-usage on thunderbird and NC-app on the desktop probably at the same time.

something is weird here.

Next try:

  • I use only separate logins to the webinterface, create a QR-Code/App-Token and then do not log out but close the (incognito/private) browser window.

I try to rule out the suspicion, that something/someone invalidates some app-token and therefore all other app-tokens that were created within the same session will also be invalid after some short timespan.

Just FYI

Ok, again me.
No success in using App-Token which were created in a websession which does not get closed…

So, I am starting to collect Issues with similar problems:

Hi to everyone following this or stumbling upon this.

I figured for a while that I should try a different LDAP-account + 2FA on the nextcloud for my daily use. And it did not happen with this account.

Since I did not use the Android-NC-App connected with an app password with the new account, I figure that the Android-NC-App must be somewhat responsible for the mess.

Thus: using the old account again, not using the Android-NC-App but still using:

  • davx5 on Android with app-password
  • thunderbird/caldav on linux with app-password
  • desktop-NC-App on linux with app-password
  • webdav-mount with app-password

There must be some bug somewhere in the android-NC-app ↔ server connection that invalidate nearly all other app-password connections.
“nearly”, because the webdav-mount app-password using dav2fs on a server never stopped working, oddly enough.

I’ll leave it to you to choose your weapons. I’ll stop using the Android-App.

You did not mention LDAP in your original query. That could be a major factor.

Another possibility that comes to mind is cookies. One of the causes for this would if you’re caching cookies inappropriately on your reverse proxy. (This would probably not impact dav2fs - at least not in the same way - since IIRC it re-authenticates using Basic Auth for every transaction and maintains no session state).

Is Nextcloud handling the 2FA or are you doing doing it via LDAP (i.e. via a password suffix)?

Can you also post your general config (occ config:list system) and apps (occ apps:list)?

1 Like

Yes, indeed, it only occurred to me that this is important after reading other problems with LDAP-authenticated accounts.

nice idea. how would I check this?

Nextcloud via the app twofactor_totp:11.0.0-dev

Enabled:
  - activity: 2.21.1
  - admin_audit: 1.19.0
  - bruteforcesettings: 2.9.0
  - calendar: 4.7.16
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contacts: 6.0.0
  - contactsinteraction: 1.10.0
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.2
  - external: 5.4.0
  - externalportal: 1.3.1
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.1
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_retention: 1.18.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - forms: 4.3.1
  - impersonate: 1.16.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - notes: 4.11.0
  - notifications: 2.17.0
  - notify_push: 0.7.0
  - oauth2: 1.17.0
  - password_policy: 1.19.0
  - photos: 2.5.0
  - polls: 7.2.4
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - related_resources: 1.4.0
  - richdocuments: 8.4.6
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - side_menu: 3.13.1
  - snappymail: 2.38.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - tasks: 0.16.1
  - text: 3.10.1
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - twofactor_totp: 11.0.0-dev
  - updatenotification: 1.19.1
  - user_ldap: 1.20.0
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0
Disabled:
  - circles: 29.0.0-dev (installed 0.21.4)
  - encryption: 2.17.0
  - files_external: 1.21.0 (installed 1.10.0)
  - nextcloud_announcements: 1.18.0 (installed 1.7.0)
  - recommendations: 2.1.0 (installed 0.4.0)
  - suspicious_login: 7.0.0
    "system": {
        "debug": false,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.mydomain"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/cloud.mydomain",
        "overwriteprotocol": "https",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "filelocking.ttl": 3600,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 1.5
        },
        "enable_email": false,
        "version": "29.0.5.1",
        "updater.release.channel": "enterprise",
        "installed": true,
        "maintenance": false,
        "loglevel": 3,
        "trashbin_retention_obligation": "auto, 7",
        "versions_retention_obligation": "auto, 7",
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "auth.bruteforce.protection.enabled": false,
        "lost_password_link": "disabled",
        "ldapIgnoreNamingRules": false,
        "skeletondirectory": "",
        "default_locale": "de_DE",
        "default_language": "de",
        "mail_sendmailmode": "smtp",
        "theme": "",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauth": 1,
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpsecure": "tls",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "spreed": {
            "bbb_server": "https:\/\/scale001.anotherdomain",
            "bbb_secret": "xxxxxxxx"
        },
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "default_phone_region": "DE",
        "profile.enabled": false,
        "updater.server.url": "***REMOVED SENSITIVE VALUE***",
        "auth.storeCryptedPassword": false
    }
}

I haven’t upgraded to 29.0.7 since there is an issue with collabora… but this is a minor current thing.

I should also add, that the “high performance backend” is in place, which might also play a role in the whole thing.