[Bug]: Case sensitive generation of app tokens not based on stored usernames

[TekkertheChaot]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I just tried to connect to my NC instance using an app token and the native login flow.
Checking Nextcloud logs i noticed following entry:

{
  "reqId": "REDACTED",
  "level": 3,
  "time": "2024-03-28T18:07:27+00:00",
  "remoteAddr": REDACTED,
  "user": "--",
  "app": "core",
  "method": "MKCOL",
  "url": "/remote.php/webdav/Saber",
  "message": "App token login name does not match",
  "userAgent": "Dart/3.3 (dart:io)",
  "version": "28.0.3.2",
  "data": {
    "tokenLoginName": "Jannik",
    "sessionLoginName": "jannik",
    "app": "core",
    "user": "jannik"
  },
  "id": "REDACTED"
}

I Initially thought this was a client problem that i have reported here but further investigation led to the possibility of this beeing unexpected behaviour on the server side.

(all mentioned tokens have been deleted before publishing this issue)

It seems, that the culprit in my case is a combination of how the App token is generated and how the login process initiates the user context. In detail:

• the native nextcloud login accepts any case variation of the username and maps it to an existing user, but retains the username used to login in a case sensitive state
• when generating a app token, it will create "new" credentials based on the username used to log in and the generated password
• as far as I can see, during the login process with an app token, the login session itself identifies as the username as it is recorded in the nextcloud user db, not the app token name

These "invalid" app tokens can't be used in my case in the native flow but is still usable for WebDAV authentication.

I am not sure if this is intended, a conflict in how different login flows are handled or something else entirely.

Steps to reproduce

1. Create a user (any name)
2. log in to this user via web with the same username but different capatilization of characters
3. create a app token (observe: app token username is case-identical to the one used in the login, not the stored username in NC)
4. try to login using the provided app token credentials

Expected behavior

Login should be possible using the native app loging flow but it gets rejected.
Although this login CAN be used in other authentication flows (I tested WebDAV).

Installation method

Official All-in-One appliance

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "maintenance_window_start": 4,
        "default_phone_region": "DE",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "upgrade.disable-web": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "REDACTED BY USER",
            "REDACTED BY USER"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "28.0.3.2",
        "overwrite.cli.url": "REDACTED BY USER",
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "app_install_overwrite": [
            "openotp_auth",
            "metadata",
            "unsplash",
            "files_downloadactivity"
        ],
        "maintenance": false,
        "defaultapp": "",
        "memories.exiftool": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/exiftool-amd64-glibc",
        "memories.vod.path": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/go-vod-amd64",
        "enabledPreviewProviders": [
            "OC\\Preview\\Image",
            "OC\\Preview\\HEIC",
            "OC\\Preview\\TIFF"
        ],
        "loglevel": 2
    }
}
www-data@7ec535cf6534:~/html$

List of activated Apps

Enabled:
  - activity: 2.20.0
  - calendar: 4.6.7
  - cloud_federation_api: 1.11.0
  - comments: 1.18.0
  - contacts: 5.5.3
  - contactsinteraction: 1.9.0
  - dashboard: 7.8.0
  - dav: 1.29.1
  - deck: 1.12.2
  - federatedfilesharing: 1.18.0
  - federation: 1.18.0
  - files: 2.0.0
  - files_pdfviewer: 2.9.0
  - files_reminders: 1.1.0
  - files_sharing: 1.20.0
  - files_trashbin: 1.18.0
  - files_versions: 1.21.0
  - firstrunwizard: 2.17.0
  - integration_google: 2.2.0
  - logreader: 2.13.0
  - lookup_server_connector: 1.16.0
  - nextcloud_announcements: 1.17.0
  - notes: 4.9.4
  - notifications: 2.16.0
  - oauth2: 1.16.3
  - password_policy: 1.18.0
  - photos: 2.4.0
  - privacy: 1.12.0
  - provisioning_api: 1.18.0
  - recommendations: 2.0.0
  - related_resources: 1.3.0
  - richdocuments: 8.3.3
  - richdocumentscode: 23.5.904
  - serverinfo: 1.18.0
  - settings: 1.10.1
  - sharebymail: 1.18.0
  - side_menu: 3.11.8
  - spreed: 18.0.5
  - support: 1.11.0
  - survey_client: 1.16.0
  - suspicious_login: 6.0.0
  - systemtags: 1.18.0
  - tasks: 0.15.0
  - text: 3.9.1
  - theming: 2.3.0
  - theming_customcss: 1.15.0
  - twofactor_backupcodes: 1.17.0
  - twofactor_totp: 10.0.0-beta.2
  - updatenotification: 1.18.0
  - user_status: 1.8.1
  - viewer: 2.2.0
  - weather_status: 1.8.0
  - workflowengine: 2.10.0
Disabled:
  - admin_audit: 1.18.0
  - bruteforcesettings: 2.8.0
  - circles: 28.0.0-dev (installed 28.0.0-dev)
  - encryption: 2.16.0
  - files_external: 1.20.0
  - mail: 3.5.7 (installed 3.5.7)
  - memories: 7.0.2 (installed 7.0.2)
  - user_ldap: 1.19.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

(posted on my NC, bc GitHub complaned: "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters). Comment is too long")

Link: EXPIRED
Password: EXPIRED

EDIT 08.07.2024:
The link and share have expired. If you need them for triage, hit me up!

Additional info

No response

[kesselb]

Thank you 👍

fyi @ChristophWurst @juliushaertl

[julien-nc]

More details on the issue: Testing with a user whoose ID is user1.

• Direct web login as User1 works
• Generating an app password while being authenticated as User1 in personal security settings produces a row in oc_authtoken with uid=user1 and login_name=User1.
• Making API requests:
  • -H "Authorization: Bearer APP_PASSWD" works
  • -u User1:APP_PASSWD works
  • -u user1:APP_PASSWD fails. Log message: "App token login name does not match" "data":{"tokenLoginName":"User1","sessionLoginName":"user1","app":"core","user":"user1"}

@ChristophWurst @juliusknorr

• Is it expected to accept a login with a different casing in the user ID?
  • If not, I guess preventing the login with a different casing solves the issue.
  • If so, when checking an app password provided with basic auth, is it expected to do a case sensitive comparison between the basic auth user ID and the login_name related with the stored app password?
    • If so, there is no issue
    • If not, I guess the fix would be to do a case insensitive check, just like with the direct login form

Wdyt?

[juliusknorr]

Is it expected to accept a login with a different casing in the user ID?

No idea, maybe @blizzz has some more insights as well?

I think there was a change in 28 (or similar) that enforced checking the login name on app passwords, so that might be where there was a behavioral change

[blizzz]

Is it expected to accept a login with a different casing in the user ID?

The LoginName is independent of the user ID. It just happens that for the local database backend, any case insensitive variation of the user ID plus the email address qualifies as valid login name.

With LDAP on the other hand it is totally custom and depends on the configuration.

This should answer the remaining questions, too.

The exception here is thrown, because the supplied login names differ:

    "tokenLoginName": "Jannik",
    "sessionLoginName": "jannik",

The login name from the session is lower case while the login name with which the token was generated contains a capital first letter.

It is expected that both match identically. I do not thing I came across different login names using our clients (unless maybe ages ago). Did you use on of them? Or is it a custom generation, @TekkertheChaot ?

[blizzz]

I think there was a change in 28 (or similar) that enforced checking the login name on app passwords, so that might be where there was a behavioral change

I am not aware of that, but I would not necessarily be informed about this either.

[TekkertheChaot]

It is expected that both match identically. I do not thing I came across different login names using our clients (unless maybe ages ago). Did you use on of them? Or is it a custom generation, @TekkertheChaot ?

The issue came up using a third-party client (saber). So far I haven't tried to log in a native NC-app using app tokens.

---

The login name from the session is lower case while the login name with which the token was generated contains a capital first letter.

This is part of the reason the issue exists.
As you said, it is expected that both the tokenLoginName and sessionLoginName match.
Unfortunately, while logging in, the sessionLoginName - so what you enter on your login on your app / integration - is NOT controllable by what you enter at login. (see my test cases in the original issue description)
It doesn't matter what capitalization you're using, as it seems it will get matched to the login-name in the database (ncName).

If it finds a match, the database-saved login name will now be used as the sessionLoginName instead.

---

Summary:

Using the tokenLoginName at login in app -> Fails, if tokenLoginName doesn't match the ncName.
Using the ncName at login in app -> Fails, if tokenLoginName doesn't match the ncName.

It sounds like the intended check is [userProvidedName == tokenLoginName], but as the sessionLoginName will always be replaced with the ncName, the check is [ncName == tokenLoginName] which always fails as soon as the token has been created.

As soon as the tokenName differs from the name in the nc-db, you can't use it in the native login flow (but valid in webDAV).

It's not communicated, that the tokenLoginName uses the case sensitive login during creation thus leading to this issue ;)

I see two solutions:

1. communicate it to the user before token creation, that it is highly recommended to log in using the ncName to avoid issues with the token
2. change the behaviour of the token generation to always use the ncName as the tokenLoginName

What do you think?

(hope this makes sense, I struggle finding the right words to explain it properly)

[blizzz]

Saber! Nice! Works for me on my private instance, but it is the all lowercase case. I'll investigate, but cannot promise it will be this year anymore.

[TekkertheChaot]

Don't worry, enjoy the holidays!

[blizzz]

I just gave it a try, but cannot reproduce it on either master or 28.

So it took test case 1. I use Saber (desktop) to authenticate and point it at my server. A browser tab opens (I am logged out) and there i log in with fully lowercase name. It succeeds. I grant access. Back at Saber it looks good, I am asked also for an encryption password, and then it it appears like a success. I see Saber files being synced to Nextcloud.

I close and restart Saber, add a new note, Save, and find new files in Nextcloud.

I do not see this error message in the log files. I can confirm in the database that the login is in lower case.

Update: even went to try with 28.0.3, but same.

[blizzz]

OK, can reproduce with manual creation and a curl call when specify the loginname with a different casing than the token was created.

[blizzz]

This check was implement last eternity in owncloud/core#25154 to fix owncloud/core#24985

The underlying issue is that without this check you could use any loginname, even pennywise, and it would succeed simply by pure presence of the token – for a while (there is periodic automatic auth check).

As is noted in the comment, next to variations of the casing, also other valid login names are not be accepted, like the email address, or anything that might be configured with the LDAP config.

The problem can be reduced, by lowercasing the login name for the comparison. This is rather a hack.

But, if we find that the name does not match like now, before giving up directly, could we actually try auth agains the backend, at this stage? @ChristophWurst

Alas, this will not be sufficient for backends where we cannot auth against, speak SAML or OIDC. Maybe, if checkPassword is not featured by the backend, we can at least let the casing-difference slip.