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

TekkertheChaot commented 8 months ago

⚠️ This issue respects the following points: ⚠️

[X] This is a bug, not a question or a configuration/webserver/proxy issue.
[X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
[X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
[X] 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. saber_hunt (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

Create a user (any name)
log in to this user via web with the same username but different capatilization of characters
create a app token (observe: app token username is case-identical to the one used in the login, not the stored username in NC)
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?

[X] 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 commented 8 months ago

Thank you :+1:

fyi @ChristophWurst @juliushaertl

julien-nc commented 1 month ago

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?

nextcloud / server