nextcloud
First (legitimate) login attempt always fails (silently)
Since having the suspicious login app enabled, every first of my own login attempts fails (of course with correct authentication data), meaning the 2FA page is not loading. Login page simply reloads, without any message. Second attempt always works.
Nothing in logs.
- How to debug this?
- How can I check/monitor what exactly happens when the 1st login attempt fails/is rejected?
Still happens on latest version (v4.2.0). Quite annoying, depending on the login duration. ANY ideas?
If you can assist me on how to prove this I certainly could.
Maybe by just disabling suspicious_login app and trying to login? Expectation:
- app enabled: 1st login attempt fails
- app disabled: 1st login attempt successfully
If there are some (debug) logs that would maybe bring some log evidence.
I think it's the bruteforce (app?):
Almost on EVERY first login attempt it just fails silently, on the 2nd one it succeeds.
NC-LOG: Bruteforce attempt from "xxx.xxx.xxx.xxx" detected for action "login".
...even that IP address space is explicitly whitelisted.
Maybe by just disabling suspicious_login app and trying to login?
Yes, that's how I'd suggest testing it.
I tested it few times in the last days, even tried to provoke it in the last hours on different endpoints (Windows, iOS) with different browsers. App enabled. Strangely it did not happen a single time, meaning: after entering username + password, the logon process did NOT interrupt and start from scratch, instead (as expected) the 2nd factor screen is provided.
Running NC v27.1.5.1 with Suspicious Login v5.0.0.
Maybe something in NC server fixed this issue? Maybe time to monitor this for a while.
suspicious_logins merely registers with Server to get notified about login attempts. It never gets involved in authentication outside of being a passive listener.
I can't think of any way it would prevent logging in - short of crashing Nextcloud outright (which would surely be logged).
I agree the problem seems elsewhere - BFP or otherwise.
I'm going to close this one out here, but if the behavior returns and there are indications it's related specifically to the suspicious_logins app we can always revisit.