Core: [10.0.4] Sessions created from application passwords result in "Login failed" errors when used

[SamuAlfageme]

Context:

Prior to 10.0.4, there was a problem with application password and the sessions left behind after deletion (see https://github.com/owncloud/core/issues/28553). This is most likely a collateral of the new logic for the fix on https://github.com/owncloud/core/pull/28879 (lacking a migration strategy maybe)

The clients send 2 auth. methods (required) on the headers for all their requests: Authorization: Basic and Cookies.

Steps to reproduce

1. Setup lockout mechanism
2. Create an application password on a 10.0.4 installation
3. Use it to log in to the Desktop client
4. Observe the server logs

Expected behavior

Everything goes smooth

Actual behavior

See https://github.com/owncloud/core/issues/30157#issuecomment-360444643; each client request results in 2 entries on the logs:

owncloud_1  | {"reqId":"b5PoKuAGyNkriyfFAMbG","level":2,"time":"2018-01-30T16:06:51+00:00","remoteAddr":"172.19.0.1","user":"admin","app":"core","method":"PROPFIND","url":"\/remote.php\/dav\/files\/admin\/","message":"Login failed: 'admin' (Remote IP: '172.19.0.1')"}
owncloud_1  | 172.19.0.1 - admin [30/Jan/2018:16:06:51 +0000] "PROPFIND /remote.php/dav/files/admin/ HTTP/1.1" 207 1551 "-" "Mozilla/5.0 (Macintosh) mirall/2.3.4 (build 8537)"

• One successful, for the Authorization header.
• One that causes a Login failed in core, that can be attributed to the Cookie -> the issue here; this makes password lockout mechanisms to trigger if present (see 0)

Cause:

https://github.com/owncloud/core/pull/29525

Related Issues:

• https://github.com/owncloud/client/issues/6258
• https://github.com/owncloud/user_ldap/issues/167

I'm assigning @IljaN since he's familiar with the https://github.com/owncloud/core/pull/28879 patch, feel free to change assignment.

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

[davitol]

Using Version 2.3.0-nightly20160929 (build 3715) OSX Desktop Client

1. oC 10.0.3 --> create app password A and app password B
2. Log in in Desktop Client with both app password.
3. Delete Password A
4. Via updater, update to 10.0.4

Result:

When I deleted the app password A, that account should have logged out, but it didn't

If I manually log out from both accounts and I try to log in again. B app password wokrs fine but A (that was the one deleted) is no longer valid
But the ticket says: https://github.com/owncloud/core/issues/30157#issue-288865373

Actual behavior

Both A and B don't work as application passwords (no account can be logged in with them, even when B is still present in the DB)

[davitol]

Other scenario tested:

Using Android 2.5.0 app

1. oC 10.0.4. Create 2 password Apps and log in android client with password app A
2. Update to 10.0.5.
3. Check Android App. It keeps logged after the update

[SamuAlfageme]

It's unclear just yet how to reproduce this. I believe my original repro steps were conditioned on using a sync client pre-2.4: without https://github.com/owncloud/client/issues/5830, same accounts on the client got just one entry on the keychain storage, leaving the last one used there (shadowing the one that was not removed on the webUI). I'm dropping sev. because of this.

So one thing I think this might be is yet another display of https://github.com/owncloud/core/issues/29779 i.e. (application password) basic auth replies include cookies, client storing these cookies & uses them as headers for next requests. And either core gives priority to Cookie headers over Authorization or uses them as fallback mechanism (like it also happens in https://github.com/owncloud/oauth2/issues/103).

Session cookies are removed on client logout/close - https://github.com/owncloud/client/pull/5383 - this together with previous facts is the reason why the accounts are still connected even when the app password was removed (Authorization: Basic ... is no longer valid while client-stored Cookie: oc_sessionPassphrase=... is).

I'm also reopening https://github.com/owncloud/core/issues/28553.

This behavior together with https://github.com/owncloud/updater/issues/457 (running clients during server upgrades) might have something to do with the "Related Issues" in https://github.com/owncloud/core/issues/30157#issue-288865373.

[PVince81]

Note: my upgrade was done with distro packages and proper maintenance mode, not updater

[PVince81]

If someone ever manages to reproduce this, we need the logs from the password failure.

If this is something like the CSRF issue here https://github.com/owncloud/android/issues/1964#issuecomment-360484533, it might look like the password expired when it fact it's something else that is just getting in the way of authentication. To the user, the password prompt let them believe that the app password is not valid any more. In the case of my wife (in that ticket), she tried logging in with her regular password on the Android app and it didn't work either.

[SamuAlfageme]

Okay, I definitely was using an older client in the first place. Updated the title and the steps to reproduce. It's pretty straightforward.

Rising priority again; this cause fail2ban/LDAP/AD locking mechanisms to go nuts (see related issues in https://github.com/owncloud/core/issues/30157#issue-288865373)

[PVince81]

Is this happening with 10.0.6 ?

What is the expectation ? Detect sessions that were broken from 10.0.4 and fix them somehow in 10.0.7 ?

[SamuAlfageme]

@PVince81

Is this happening with 10.0.6 ?

Just checked with a fresh 10.0.6 installation. It does, yup. Same "Login failed" polluted logs.

For the expectation I'd say core is lenient enough when it comes to this. I'd say dropping those sessions will result in new, valid ones after next request containing an Authorization: Basic header that the clients will then use.

[PVince81]

Dropping broken sessions sounds good.

[SamuAlfageme]

Just confirmed https://github.com/owncloud/core/pull/29525 is the real cause of this issue.

Created a really dumb patch by cherry picking those core-affected files in https://gist.github.com/SamuAlfageme/2004bd6c7abd2c08a452bef2ed7a1f5c (can be git apply -R on the root installation wo/ conflicts)

[PVince81]

From my understanding: the basic issue without lockout mechanism only logs a line "Login failed" but clients still work fine. It's only when a lockout mechanism is in place like brute force protection that it becomes critical as it would react on said messages to block the account.

I've updated the OP to add a step to setup lockout mechanism to trigger the critical issue of locked out accounts.

[PVince81]

We need to revert https://github.com/owncloud/core/pull/29525 to fix this, but this will break Oauth expiration again since this was the original purpose of this PR.

@DeepDiver1975 @IljaN any idea how to fix this in a way that works for both ?

[dercorn]

Just for the record: this is issue affected me as well. After changing my password, my IP got banned from every device that had a client on it.

[PVince81]

@dercorn do you have any brute-force protection in place like fail2ban ?

[PVince81]

test plan here for once we have the fix: https://github.com/owncloud/QA/issues/529

[SamuAlfageme]

Reopening because of https://github.com/owncloud/core/pull/30364#issuecomment-363750684:

⚠️ Still throws the "Login Failed" messages when using OAuth2 (v.0.2.1 wo/ https://github.com/owncloud/oauth2/pull/112) together with application passwords

Will continue posting the results of deeper exploration on https://github.com/owncloud/QA/issues/529

[PVince81]

https://github.com/owncloud/core/pull/30591 was merged now, close ?

[DeepDiver1975]

30591 was merged now, close ?

:question:

[bcutter]

I implemented it manually (2 files, without test file) on OC v10.0.6.1 a few seconds ago. I´m paying attention to the clients and OC log file, will report soon if it fixed the issue.

Update: Log empty regarding those issue for more than 30 minutes now, so: cautious all-clear signal.

[Emil-G]

Seems to have solved the issue of getting kicked out of LDAP here. Cheers :+1:

[bcutter]

Update: Nope. Even all the

Warning core Login failed: 'Username' (Remote IP: '192.168.178.24') a day ago

are gone now, there still are

Warning core    Login failed: 'xdXOt13JKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' (Remote IP: '192.168.178.24')  an hour ago
Warning core    Login failed: 'xdXOt13JKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' (Remote IP: '192.168.178.24')  2 hours ago
Warning core    Login failed: 'xdXOt13JKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' (Remote IP: '192.168.178.24')  3 hours ago

every hour.

[DeepDiver1975]

I am working on a solution to fix the last log entries.

[DeepDiver1975]

I am working on a solution to fix the last log entries.

30421

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.