Android: Not possible to update password or remove account?

[stefan2904]

My story

My Nextcloud password (via LDAP) changed (it does so regularly, and so should yours).

Now the app cannot access the cloud anymore (makes sense).

Issue

• It is not possible to change the password the app is using
• It is not possible to remove an account from the app

[AndyScherzinger]

@stefan2904 you should be able to remove the account going through the main menu's header toggling the menu to see "Manage Accounts", opening your account there should then show the account and the top right menu should have the menu item "remove account".

@stefan2904 @tobiasKaminsky we removed the change password menu item since the app should work with app tokens that get generated via the login flow. @rullzer does changing the LDAP-based password lead to revoking app tokens? @tobiasKaminsky shouldn't a changed password lead to the login screen popping up?

As for

it does so regularly, and so should yours

I need to disagree here, since research shows that regular password changes make password less secure since people often choose to just increment a value at the end of the password.
While your point is correct that this should work nevertheless. ;)

[stefan2904]

opening your account there should then show the account and the top right menu should have the menu item "remove account".

Hm, I tried that, but the account page did not load (error, because authentication failed) - turns out the top right menu you mentioned is there anyways - but very well hidden in the organizations header image, and the error distracted me from looking up. So a mistake on my site - and maybe feedback for the UI.

we removed the change password menu item since the app should work with app tokens that get generated via the login flow

interesting. so that's a different thing than the app specific password?

does changing the LDAP-based password lead to revoking app tokens

I can only confirm that I was not able to access the cloud data anymore as soon as the LDAP password changed. Unfortunately I cannot reproduce it now, since I removed and added the account.

I need to disagree here, since research shows that regular password changes make password less secure since people often choose to just increment a value at the end of the password.

... which is better than not changing it at all.
(Our organization eve requires people to chose a password which is different than the old one in more than 3 digits.)
But a complicated topic, since we don't live in password-manager-age yet. ;-) And probably the wrong place to discuss this ...

[rullzer]

@rullzer does changing the LDAP-based password lead to revoking app tokens?

In Nextcloud 14 regular password changes (so DB user backend not LDAP) will properly propagate to all the apptokens. LDAP is not yet taken care of. But the pieces are in place. However this will require more enginering work as LDAP doesn't notify us about changes but we have to do some bookkeeping there.

So the short awnser. LDAP bases password changes lead to revoking the app tokens yet.

[NESC1US]

with password change from outside of next cloud android app, entire configuration of all 'synchronised' folders is removed and needs to be recreated every time password changes.. Argh!

[AndyScherzinger]

with password change from outside of next cloud android app, entire configuration of all 'synchronised' folders is removed and needs to be recreated every time password changes.. Argh!

@tobiasKaminsky is this really the case because this shouldn't happen in my opinion

[NESC1US]

I guess this requires a clarification: one can't create a second account with same user name, so the original account needs to be removed in case of changed password, as password change is not possible within the android application once the password is already changed outside of the app.

[tobiasKaminsky]

Changing password on web ui has no effect, if you already use the new weblogin flow.
If you then revoke the security token, the app will give show you the login again.

Is your user a very old user / registered on device long time ago?

[r2evans]

The current method for changing passwords is unsustainable given the use-case of a cloud-stored password manager file (e.g., KeePass or others). When I start this process, it says

Remove account ... and delete all local files?

(emphasis mine) If I do that, I no longer have my password available on the phone. This means that instead of using a password manager to deal with the hard-to-remember-and-type password, I have to read it off of another screen and type it in, which is negating one of the benefits of using a password manager. I think that app-tokens can help to improve security, but I would not expect an app-token to be "unchanging", meaning that it too should be changed periodically.

What is the issue with updating a password to a given account? I don't know of any app I use on ny phone that doesn't allow me to change the authentication non-destructively. Does this restriction provide additional security in any context?

[OVMorat]

Agreed with r2evans
I am testing for deployment to 90 users with AD passwords who authenticating to Nextcloud via LDAP (in this case via Zimbra). AD passwords change every 30 days but the Nextcloud app continues to authenticate with the previous password causing account lockouts.
We need the return of "Change Password" to allow users to change the credentials with which they auth to the server.
Ideally, the app should recognise a login failure, stop attempts to authenticate and warn the user to update his password.

[r2evans]

@tobiasKaminsky, when you talk about the "weblogin flow", do you mean the use of tokens?

With NC15 I think we got the ability to continue using a token when the user changed their password (through the UI). In the case of external passwords (e.g., AD), the token is not usable until the user logs in on the webui with the new password to refresh the verifiability of the token. This is a step forward, but two issues remain on this flow:

1. Login failures on the Android client repeat with no notification to the user, possibly triggering lock out.

2. We still cannot rotate tokens without removing and recreating the account. There is nothing special about tokens from a password perspective; in fact, they are a little weaker since they are a known length with a known set of characters (typically alpha or alphanumeric only). For many this might be a better-than-average password strength, but it should still be rotated periodically.

Can you give a hint to a milestone or similar reflection if recognized importance for this problem?

[stale[bot]]

This request did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[r2evans]

@tobiasKaminsky?

[jammon]

Is it true that this issue is closed because in some given 6 weeks period nobody decided to work on it?
I think that @stefan2904, @r2evans, and @OVMorat's points are still valid. The android app should have a "Change Password" because - well - passwords change. Actually I don't understand why it didn't have this option in the first place. Is there a security aspect I didn't see?
To be clear: While it may not be necessary to change the accounts password through the Android app, there should be a way to tell the app that the password has been changed through e.g. the web ui or to change to a unique app password.
@tobiasKaminsky?
Thank you all for taking care!

[tobiasKaminsky]

When connecting with this app to server we generate a app password, which stays the same even if one is changing its login password.
So there is no technically need to change a password within this app.

It might be a enhancement request, similar to change avantar, or updating profile information.
Unfortunately we cannot do this on client side, as there are several user backends, e.g. LDAP where NC (even in web ui) is not allowed to change the password.
So there is no need and no possibility to change the password.

[jammon]

Thank you for coming back on this!
I didn't know that the android app automatically generates an app password, which doesn't have to change. This is pretty cool!

[r2evans]

Up front: from a security standpoint, I do not believe that Nextcloud is showing any malpractice here. My issue is that changing the password in my android client is always a destructive operation.

@tobiasKaminsky, I appreciate you continuing to comment on this thread.

So there is no technically need to change a password within this app.

You are assuming that the app-token complexity is perfectly-sufficient¹, that complexity is relatively future-proof, and app-tokens need not be included in security discussions about password age. I strongly disagree.

It might be a enhancement request, similar to change avantar, or updating profile information.

Comparing security with aesthetics is faulty logic.

Unfortunately we cannot do this on client side, as there are several user backends ...

Okay, I get that you don't want to be responsible for changing the password on the server. I agree, that's sound and fair.

But that's not what I believe this issue was meant to resolve. My interpretation is "a way to invalidate the app-token stored in the android client and set a new one without deleting the account on the device".

---

Even though "change every 90 days" security has been shown to not always improve overall security (due to social problems, not technological ones), that doesn't mean that users need not change them ever. And while I believe there are other controls in place (e.g., client app signature, ip address, http header) in order to accept an app-token as sufficient in lieu of 2FA requirements, those controls must not be trusted wholly, just used as a factor in the authentication calculus.

When your credit card is stolen, you call and cancel/change your card number right away.

When one of my electronic devices is stolen, I immediately revoke all app-tokens and reset them. This means that I must remove each of my nextcloud accounts and set them all up again. While I "hope" that the files cached on the android could be used in the new-accounts, is that safe enough to rest all beliefs?

Footnotes:

1. I admit that the entropy of these app-tokens is theoretically 149 (log2(62^25) I think), which is currently considered very strong on most entropy scales. But I also believe that that alone is not enough to rest.

[AllirionX]

I am late to the party, but not having the opportunity to invalidate the app-token and trigger a new login flow was painful for me this week. Due to a power outage, the nextcloud install got corrupted. I reset it using a one week-old backup, and recreated the users that had disappeared during the week gap.

Because, it is impossible to invalidate the app-token, all the users had to remove the nextcloud account and to re-add it. Some users also synchronised their phone contacts through DAVx5: the DAVx5 account being linked to the nextcloud account they also had to create a new DAVx5 account, and migrate all the contacts from one account to the other.

I think having the ability to re-authorize the app would help a lot in case the app-token becomes invalidate server-side (database rollback, app-token changed for security reasons etc.)