Proposal for Integrating an Additional Password Protection Module for Folders in Nextcloud

[turok0000]

The module I developed adds an additional layer of protection for user data in Nextcloud — the ability to set a separate password for a selected folder.

The password for the protected folder is not linked to the Nextcloud account password and is used as an additional layer of authentication.

The main idea is that standard authentication in Nextcloud is not sufficient to access the contents of a protected folder. When attempting to open such a folder, the user must additionally enter the password set for it.

Once protection is enabled, the module restricts access to the contents of the folder until additional authentication has been completed. This means that even if an unauthorized person gains access to an already authenticated Nextcloud account, they will not be able to simply open the protected folder through the web interface and view the files stored inside it.

At the same time, Nextcloud’s existing user system, access permissions, and authentication continue to work as usual. The module represents an additional layer of protection on top of Nextcloud’s existing access model, rather than replacing it.

How It Works

The user selects a folder that needs additional protection and sets a separate password for it.

After protection is activated:

• the folder is marked as protected;
• when attempting to open its contents, an additional password is requested;
• without successful password verification, access to the contents through the web interface is blocked;
• after successful authentication, the user gains access to the folder;
• the mechanism works independently of the user’s primary authentication in Nextcloud.

In practice, this makes it possible to create an additional private area within the regular user storage — a kind of “second layer”, access to which requires separate confirmation.

Current Implementation

At the moment, the module has been implemented and works properly in the web version of Nextcloud.

The project’s source code is stored in a private GitHub repository and has not yet been made publicly available.

Within the web interface, I was able to implement the core protection logic: identifying protected folders, requesting an additional password, and restricting access until additional authentication has been completed.

The Problem Encountered

The main problem appeared when using the official Nextcloud mobile applications for iPhone and Android.

The mobile clients use their own mechanisms for working with files and local caching. Because of this, some data may be retrieved or may already be stored on the device independently of the additional password verification implemented at the web interface level.

As a result, the protection works correctly in the browser but cannot guarantee the same level of access restriction through the mobile applications.

This is an architectural limitation of the current implementation.

Simply modifying the web interface is not sufficient, because full protection must also be enforced when accessing files through API, WebDAV, and mobile clients, and must properly interact with local caching mechanisms.

What Is Required for a Full Implementation

In my opinion, to turn this mechanism into a fully integrated Nextcloud feature, it needs to be integrated more deeply into the platform’s architecture.

Additional authentication verification should take place not only in the web interface, but also on the server side when protected data is accessed through different methods.

The behavior of the following must be defined separately:

• WebDAV;
• Nextcloud API;
• Android client;
• iOS client;
• file synchronization;
• local cache;
• previously downloaded files;
• shared folders and links;
• background synchronization;
• file downloads and uploads.

The issue of already cached data is particularly important: if a file was downloaded to a mobile device before a password was set on the folder, server-side protection alone cannot delete an already existing local copy. Therefore, a full implementation will require support for the protected folders mechanism directly within the mobile clients.

Project Goal

My goal is not simply to add a password prompt to the web interface, but to create a complete additional layer of folder protection that will be applied consistently regardless of the method used to access Nextcloud.

I am ready to provide the Nextcloud team with the source code of the existing module, a description of its architecture and current limitations, as well as participate in the further development of the solution and its integration at the platform level.

[turok0000]

I have added Simon as a developer to the private GitHub repository. You can review the source code, the current implementation, and the module’s functionality in advance.

Thank you for your time.

[tflidd]

Sounds a bit like the client-side encryption …

[turok0000]

I didn’t quite understand you. The password for the folder is set in the NC account. The data in the folder is not encrypted, but access to it is restricted by a password so that outsiders cannot see it. Even if the account is open and you have allowed someone to view a specific folder with photos, that person will not be able to access the password‑protected folders in the cloud. Each folder can have its own unique password.

[tflidd]

Ah ok, not sure perhaps you could do something with tags, that folder with a specific tag are excluded from sharing and that they cannot be accessed (and you cannot share them by accident).

If you want to sync this and reproduce the behavior on clients, that will be tricky. What happens when you don’t have internet connection, can you just locally verify the password (some pw database needs to be synced with the client). What happens when the client is stopped, is this data encrypted/deleted? Or do they remain in the cache in clear?

And if it shouldn’t be seen by others, couldn’t be the client-side encryption with the extra-password be a good way?

[turok0000]

Yes, using tags could indeed be useful as an additional layer. For example, protected folders could be marked with a specific tag, and that tag could be used to prevent accidental creation of public links or to exclude such folders from certain sharing scenarios. However, a tag alone does not solve the whole problem, because access still has to be enforced on the server every time files are accessed through the web interface, WebDAV, APIs, mobile apps, or the desktop client.

My current implementation is not client-side encryption. It is an additional server-side access control layer for folders. The folder password is not connected to the main Nextcloud account password. Each protected folder can have its own separate password. The password itself is not stored inside the folder and is not synchronized to devices in plain text. Only a password hash is stored on the server and used for access verification.

At the moment, the protection works as follows:

• in the web interface, the folder cannot be opened without the additional password;
• through WebDAV, access to the contents of a locked folder is blocked;
• uploads, deletes, moves, copies, and file creation inside a locked folder are denied;
• the contents of a locked folder are hidden from WebDAV listings;
• creating new public links for a locked folder is blocked until it is unlocked;
• after the correct password is entered, the folder is unlocked for that user for a configured period of time.

The main difficulty is indeed on the client side. If the user is offline, the current server-side implementation cannot verify the password, because verification happens on the server. For full offline support, this feature would need to be implemented at the platform level and inside the official Nextcloud clients. In that case, the client could synchronize hidden hashes for protected folders in advance and perform local password verification without an internet connection.

Mobile apps would also need their own UI module: when the user taps a protected folder, the app should display a password prompt and only show the contents after successful verification. For the desktop client, a simpler approach may be possible: if the folder is locked, the client could avoid opening it locally and instead redirect the user to a browser page where they can enter the password and unlock it.

Regarding the local cache: if a file has already been downloaded to the device before the folder was locked, or while the folder was unlocked, the server cannot reliably delete an already existing local copy. After the next synchronization, the server can expose the locked folder as empty or inaccessible, but physically removing the local cache depends on the behavior of the specific client.

If the desktop client or mobile app is closed and opened again, the contents of the protected folder usually disappear after the state is refreshed. However, if the app remains open, the local cache may remain visible after the folder has been viewed until the client is restarted or synchronized again. This is a limitation of the official clients, because they currently do not have a built-in protected folder mechanism with a separate password, local offline verification, and managed cache handling.

Client-side encryption could indeed solve the local cache problem more strongly, because the data on the device would be stored encrypted. But that is a different protection model. If the user loses the encryption password, the data cannot be recovered. In my case, the goal is different: to add a reversible additional access layer on top of the standard Nextcloud model, without encrypting the files themselves.

So the current implementation already strengthens protection on the server side and through WebDAV, but full and consistent behavior in Android, iOS, and desktop clients would require support at the Nextcloud platform level and in the official clients: synchronization of hidden hashes for offline verification, a password prompt in mobile apps, proper handling of locked folders in the desktop client, control or disabling of offline access, and managed cleanup of the local cache for protected folders.