App passwords should be optional

[GitHubUser4234]

Hi,

There are environments where security measurements need to be enforced including limiting users to only login through WebUI using OTP (global OTP enforcement is an enhancement already in the works at #2348) and disallowing file access without OTP login through applications/desktop clients.

Similarly, environments might require to employ password policy which doesn't cover app passwords either and with stringent security requirements this might not be acceptable.

Therefore it would be great to have an option on the administration page to disable the app passwords feature completely, thanks ~

[MorrisJobke]

cc @karlitschek @ChristophWurst @LukasReschke Does that make sense?

[skjnldsv]

@ChristophWurst make any sense?

[ChristophWurst]

nope. they are becoming more and more important in fact and the goal is to have all client connections use them.

[GitHubUser4234]

@ChristophWurst : People including me are asking whether the request is making sense, but your answer does not touch any of the items mentioned in the request. Disappointed.

We to hack the code and remove app password related sections, and it became even more difficult after such logic appeared in the hard-to-maintain vue-settings-personal-security.js .

[ChristophWurst]

Hiding the settings is security by obscurity at best. App passwords are an integral feature of the Nextcloud authentication system. Without those client connections would not be as secure. And some features like remote wipe would not be possible.

So this is not about answering questions. The request is simply against our goals, so this is a wontfix.

[GitHubUser4234]

Phrases like "client connections would not be as secure" indicate that the request is not understood correctly, in fact the whole purpose of disabling app passwords is for security reasons!

To explain in other words:

In environments like ours where security has highest priority, 2FA is enforced for all users, for their own safety. Here a screenshot:

For the very same reason, users are under no circumstances allowed to skip 2FA, which they could by resorting to the app password function. Therefore, the function needs to be disabled in these cases.

Implementing such a switch should be pretty easy, adding one to config.php would suffice.

[ChristophWurst]

But how would you expect any clients to connect if they can't use app passwords?

[GitHubUser4234]

They are not allowed to connect, it's that simple. If security is highest priority, the "Enforce two-factor authentication" flag is supposed to mean what it says, making it literally impossible to circumvent it in any way, also not by using clients / app passwords. Grateful if this could be done, thanks.

[MorrisJobke]

They are not allowed to connect, it's that simple. If security is highest priority, the "Enforce two-factor authentication" flag is supposed to mean what it says, making it literally impossible to circumvent it in any way, also not by using clients / app passwords. Grateful if this could be done, thanks.

Then listen for this event and delete the app passwords right when they are created:

server/core/Controller/AppPasswordController.php

Line 116 in 5bf3d1b

$this->eventDispatcher->dispatch('app_password_created', $event);

Because app passwords can only be created after you authenticated via 2FA and allows a single device to interact with the instance. In that way you can revoke access on a per device level, which is not possible with pure username password authentication without 2FA. So this is more secure and provides the needed security. But if you really want to mess around with that: feel free to do so - it's open source and you can install your own apps, that mess around with every detail.

[GitHubUser4234]

Hi Morris,

Thanks for the reply.

Because app passwords can only be created after you authenticated via 2FA and allows a single device to interact with the instance. In that way you can revoke access on a per device level, which is not possible with pure username password authentication without 2FA. So this is more secure and provides the needed security

But this doesn't really sound convincing. This still leaves control to the users. Meaning they can use 2FA to enable a 1FA channel, undermining the safety concept that is intended by enforcing 2FA at all times. This might be negligible for the sake of convenience in some cases, but it might be a huge safety concern in others. That's why giving an option was proposed to cater for both situations.

[MorrisJobke]

But this doesn't really sound convincing. This still leaves control to the users. Meaning they can use 2FA to enable a 1FA channel, undermining the safety concept that is intended by enforcing 2FA at all times. This might be negligible for the sake of convenience in some cases, but it might be a huge safety concern in others. That's why giving an option was proposed to cater for both situations.

Still this will allow to basically make it only work via the web UI and render all clients (desktop and mobile apps as well as CalDAV and CardDAV, etc) useless. This is nothing we plan to add as a configuration option AFAIK. If you really want to have this feature, then hide the UI via CSS and the custom_css app and then delete all the generated app tokens via the above event in the moment they are created (if somebody wants to work around this).

[ltsavar]

I've to agree with GitHubUser4234. It would be good to have the possibility to disable app passwords at least in the webui. But if its not possible i guess i'll hide via CSS as well...

[WorksAtAUni]

Agree. There should be a way to disable them outright. The core functionality of the product is great, but to suggest that the user can violate corporate policy because they have already authenticated once via 2FA is not a really strong argument when they have to authenticate 2x for everything else frequently. Having to go in and code a delete action after a create event or hide the choice via the custom CSS app seems like a unfortunate set of options. And yes, there are entities that want it just to be the browser..... It might not be the typical use case, but it is a valid one.

[pboguslawski]

See #33879

[rriemann]

We would use the option to disable app passwords in our Nextcloud Enterprise installation.