nextcloud
discussion: does 2FA suggest/mandate application passwords?
2FA is "A Good Thingâ„¢". It can and will impact other clients, though, such as the desktop app and caldav/carddav clients. What is the suggested way to deal with this?
- Application passwords: these really aren't much more secure than 1FA with a username/password. The difference being that the application password is often created by the service, meaning it has assured complexity/entropy. This is perhaps better than nothing, but I think it adds a little false-confidence in that I don't know how it mitigates brute-force password-guessing.
- Implement TOTP in the clients; unfortunately, though the desktop app is well-controlled, adding this complexity to DAV-related services is a very big undertaking (I think), involving numerous different implementations. Even if you don't add TOTP storage to the *DAV client, the user then must do the 2FA every time the app wants to sync, very bothersome indeed.
Bottom line: the way I understand it, if you enable 2FA, anybody using it will lose automated sync. If you enforce 2FA's use, you lost automated sync for (almost) all users. What am I missing?
Hi @r2evans,
It can and will impact other clients, though, such as the desktop app and caldav/carddav clients. What is the suggested way to deal with this?
Clients should use app-specific passwords: https://docs.nextcloud.com/server/11/user_manual/session_management.html#managing-devices
This is perhaps better than nothing, but I think it adds a little false-confidence in that I don't know how it mitigates brute-force password-guessing.
Nextcloud does prevent brute-force attempts out of the box since Nextcloud 10.
Implement TOTP in the clients
Nextcloud's 2FA is plugin-based and TOTP is just one possible 2FA provider. We simply cannot implement it for all possible providers.
Bottom line: the way I understand it, if you enable 2FA, anybody using it will lose automated sync. If you enforce 2FA's use, you lost automated sync for (almost) all users. What am I missing?
Clients won't be able to connect if they use the login password and not an app-specific password. What we're still missing is some kind of 2FA-detection on the client side to distinguish between wrong password and use an app-specific password.
As long as there are app-specific passwords without 2FA, I do not know of a way to mitigate this: unless/until all connecting clients utilize the same level of authentication, the system will only be as strong as the weakest component (i.e., non-2FA). (In this case, it's still relatively good with tarpitting to combat brute-force attacks.)
Assuming users want to access NC via something other than the web UI, clients are required, so this would be a multi-step multi-client discussion:
- file sync (both desktop and mobile, "controlled" by NC)
- caldav and carddav, currently not controlled by NC
- mobile: there is a wishlist (perhaps very low priority) to add *dav capabilities to the mobile (https://help.nextcloud.com/t/desktop-mobile-apps/129/105), but this is perhaps more feasible due to the mobile platform's concept of "accounts"
- desktop is harder, since many more calendar/contacts clients exist (e.g., outlook, thunderbird, sunbird); this is obviously a hanging point
Thanks for the feedback. I realize this discussion doesn't belong in this repo, more the wishlists and other "issues".
I agree that app-pws arent perfectly secure but you cant make everything compatible to 2FA just bevcause the protocols dont work that way, for example if you have 2FA on your Email provider, you cant get your emails via plain imap or pop3 without the usage of an application password or similar mechanism.
one way would be for example attaching a totp code to the password, which kinda works, but only once, because you would have to enter your password with the new code again and again.
in case that session negotiation is possible in a good way (for example the apps) it would be possible that the app password gets invalidated upon login, but instead the app gains another way of keeping the session, for example it creates a signing key and the cloud service remembers the pubkey, and all new requests get made through that session signing key.
that way the app-password would be only a negotiation password.
in case of webdav this might be possible if it is used over SSL/TLS, if the client supports client certificates, although the ways would be different, you make a private key and self-signed cert on your machine, NC gets the self signed cert or the pubkey and stores it for the user,
then upon logon to the TLS-Webdav the user wont do his username/password but instead with client cert and do it with that. NC checks the signatures and whether or not the key belongs to some user. if yes, let him in.
the large advantage of using client certs instead of passwords or cookies is that the certs arent floating around in the internet all the time, so even if your active session gets MITM'ed they wont be able to see anything more than what's happening because no matter how much the MITM logs, they wont be getting past the client cert auth. of course this is provided that the inital setup occured in a trusted setup.
another thing that could be done would be restricting application password only for certain uses, for example a password for file syncing only needs access to the files and not any account stuff, a password for a caldav client wont need anything more than caldav.
