Repository navigation
Make login flow v2 more phishing proof #26944
Description
Ref #26943
The problem
Login Flow v2 has the same weakness that OAuth "device code" phishing campaigns exploit. An attacker starts a login flow and sends the victim the link. The victim logs in and clicks "Grant access", and the attacker receives an app password.
What exists today
The grant page (core/src/views/LoginFlowGrant.vue) shows only a client name, which the attacker controls because it comes from the User-Agent, plus a generic warning.
- A warning is available but generic: Improve visibility of login flow v2 warning #26943
TODO
- Threat modelling: what an attacker can control in the flow, and what the user can actually check.
- Countermeasures, for example:
- showing where the flow was started (IP and user agent?) next to the user's current browser, and warning when they differ
- number matching between the client and the browser, as an opt-in protocol extension that stays backward compatible
- Building it in PHP (the core controllers) and Vue/TypeScript, with tests.
Activity
Make security warning stand out more
jospoortvliet commentedon Jan 6, 2026
2 things done, anything else planned?
fput commentedon Nov 3, 2026
I did some threat modelling to better understand the phishing risks in the current login flow v2:
Assumptions and attacker capabilites:
Assuming a standard Nextcloud installation, where the attacker can reach the Nextcloud server and can send the user a link. The attacker has not compromised Nextcloud, TLS, the browser, the Nextcloud client, or the user's device.
The attacker can do the following during the login flow:
POST /index.php/login/v2)User-Agent). The attacker could impersonate an official clientI see two kinds of phishing attacks:
The main vulnerability is that in the current design, the user is responsible for detecting phishing attacks, by verifying the login request.
There are several problems in the current design:
Mozilla/5.0 (Macintosh) mirall/35.0.1 (Nextcloud, macos-24.6.0 ClientArchitecture: arm64 OsArchitecture: arm64). It starts with "Mozilla" for technical reasons, but users will not understand this and will likely get used to seemingly invalid labels on these requests.I have some ideas to properly mitigate these issues, but doing so requires changing the login protocol and thus requires modifying the clients.
For now, I recommend addressing problems 2, 4, and 5, which can be done entirely on the server without changing the clients. I have implemented this in PR #66223 by redesigning the UI to make the approval decision more explicit and providing better context to allow users to make more informed decisions. I also added verification that the client and browser IP matches and display a warning if it differs.
This is how my proposed redesign looks like:
fput commentedon Nov 3, 2026
I can think of further countermeasures, but they require changes to the protocol and thus also change the existing clients. So I did not implement this for now. Here are some ideas, though, depending on whether we need to only support same-device use cases or also cross-device use cases.
Same-device (i.e., when the new client runs on the same device as the browser/existing session that approves the new client, e.g. the desktop or mobile Nextcloud clients): This is easier to secure, e.g., using a local return channel as in RFC 8252. Desktop clients would open a desktop browser. Mobile clients would open a mobile browser. Both Android and iOS support local return channels. The browser redirects using some local-only scheme (loopback redirect, custom URI, verified app link), which prevents remote phishing attackers from accessing the login secret.
Cross-device (i.e., when the new client runs on a different device as the browser/existing session that approves the new client): This is much more complex. RFC 10027 provides some recommendations. Essentially, we need some other way to establish proximity between both devices if we want to automatically detect a remote phishing attacker. E.g., FIDO2 does this using BLE to establish proximity, but this requires two client devices with BLE support.