Nextcloud 13.0.1: New Security Tokens Invalid?

A quick Github search doesn’t turn up anything that looks like my issue, so I’m posting here to see if it’s just a me problem. Any help would be greatly appreciated.

Server: Ubuntu 16.04 with PHP 7.0.4
Client: Nextcloud for Windows version 2.3.2, build 1

Any tokens created since the 13.0.1 update don’t appear to work, giving 401 unauthorized or Wrong password. errors, depending where I try to use them. Existing tokens continue to work as expected.
I’m not certain whether I’ve created any tokens between 13.0.0 and 13.0.1, but the issue exists for me in 13.0.1, at least.

Steps to replicate it:

  1. Go to Settings -> Security -> Create App Password
  2. Attempt to use the new token with Nextcloud’s Windows sync client, or from any browser on the login page.

Logging only shows the Login failed warning with my username and IP.

I can confirm this issue. However, the existing tokens stopped working for me too.
Logging into the web interface and issuing new tokens works. However, the new tokens can’t be used to login either.

I’m using Nextcloud 13.0.1 with PHP 7.2 and Apache.

My client is e.g. the official Nextcloud Android App and davdroid.

I’m able to provide an account to my instance to a developer.

Hmm… I can’t confirm that, actually. All of my prior 13.0.1 app tokens continue to work and I have just today issued myself a new app token, which also worked without any issue.

Do any one of you use 2FA?

No 2FA here. Also no server-side encryption or end-to-end encryption. User authentication is internal to Nextcloud, as per default.
I’ll share some additional info here, and hope something helps narrow it down. I would also be willing to give someone an account to help troubleshoot.

This is an LXC container made with debbotstrap. The host and all containers are Ubuntu 16.04 LTS. I did the manual Nextcloud installation on the guest, and recently ran the web updater to get 13.0.1. I also have an Apache reverse-proxy container to handle HTTPS, so my Nextcloud root is <site>/nextcloud, rather than cloud.<site>/.

Yes, I am using 2FA.

The desktop nextcloud client prompts for a new password and a newly issued app password doesn’t work either.

The authtokens are stored inside the NC database in the table oc_authtoken. Can you check, if your newly created authtoken has made it into the database?

Well, with no apparent explanation, new tokens appear to be working again. I’ve run no updates of any kind on the relevant systems, nor have I changed my configuration any. I don’t think CPU or other resource usage by other containers had anything to do with it either.

I can create some more tokens a bit later today, and watch for how long they take to get to the database.

Edit to say: logs contain nothing but previous failed login attempts, so no leads there either

I am still encountering this problem.

@budy Yes, the authtokens are in the database. The descriptive name which I entered in the web interface is there.

This is the query I used:
select id,uid,name,password,token from oc_authtoken where uid like 'Myusername' order by id desc limit 1;

Trying to login with the app password from the Linux desktop client produces this debug message in the log:

Sabre\DAV\Exception\NotAuthenticated: No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is misconfigured, No ‘Authorization: Bearer’ header found. Either the client didn’t send one, or the server is mis-configured

Now, it works for me too.

After digging a bit deeper, I found many entries in the table oc_bruteforce_attempts from my IP address. I removed all entries from my IP and it started working again - old and new app tokens.

In between I downgraded PHP from 7.2 to 7.1, Nextcloud from 13.0.1.1 to 13.0.0.14 and upgraded both again to their most recent versions. Then disabled TOTP second-factor auth. After everything was working again I re-enabled it.

I’m not sure what happened since the initial login failure should’ve not been cause by a “brute force attempt”.

The whole time user and admin logins in the web have been working. Desktop and mobile client logins with saved passwords didn’t work.

Brute force protection shouldn’t have triggered in my case either, though I don’t know whether it did or not. This may be indicative of a bug in that code, or may be just a fluke.
Needless to say, my checking of timing within the database turned up nothing unusual; if that was the problem before, I can’t recreate it now.

I’ll mark this as solved. Thanks for your help in troubleshooting, budy, and the additional information, jmpnext. I’m looking forward to more of Nextcloud. :wink:

At me too such problem. Upgrading to 13.0.2 did not fix the problem. Are there other solutions?

Hi, could you check your system time? With TOTP it is important to synchronize your system time with the internet (keyword NTP). Maybe you can check that first.

Any error messages for Nextcloud or your system?

Time is right. Old tokens work, but new ones do not, the error “Wrong password”

Relating to a possible partial fix from before, have you tried disabling brute force protection or removing any oc_bruteforce_attempts entries from the database?

Brute-force is disabled. All entries in oc_bruteforce_attempt deleted. But still does not work.

Is there any debugging mode to find the problem?

The problem might be related to the currently-broken (imho) implementation of app-tokens, as shown in issue #2581. The bottom line is that when you change your normal password, all app-tokens are immediately invalid. (This goes against my understanding of app-tokens, and how they behave on other sites like github, gitlab, etc.)

PR 9485 addresses this but is slated for NC14, and so far there has been resistance to backport it to NC13 (or further). Until then (it might be a while), this design-feature might negate most benefits of using app-tokens.

Hey, uh. I know this is very much the wrong place to do this, but I don’t see a private message option on this site. But Mactrent, if this is the right person. It’s me, Talohn from cinnagar on IRC. Could we talk? I hope this is the right Mactrent.

I recently had some problems with brute force attacks. One single app couldn’t login and was blocking users and app passwords. I set up a whitelist for my network now.
Today I looked in the table authtokens. There is a row password_invalid. It would be nice if this information would also be available in the app password list. It is very confusing if an app password isn’t working anymore.
Also an information about the reason would be nice, why a password got invalid.