Provide custom SSE algorithm/user secret

[summersab]

Current Status
The only available encryption algorithms are the bundled SSEv1 and SSEv2 algorithms.

Feature Description
For certain advanced implementations, it would be useful to be able to define a custom SSE algorithm or provide a custom user secret.

Additional context
For my particular situation, I have my Nextcloud instance's master key disabled, and I am using Keycloak to pass a custom user secret during SSO login. I would like to implement a SSE algorithm that uses this custom user secret.

I can think of a few ways to do this, but I wanted to discuss before submitting a PR:

• (Easiest) In the admin settings, the sysadmin can provide the class name of their custom SSE algorithm.
• Provide a middleware or event listener for the sysadmin to hook into the passwords app and use their own custom SSE algorithm (or simply their custom user secret).
• The sysadmin can write an app that loads their custom SSE class that implements ObjectEncryptionInterface. Then, the passwords application can use get_declared_classes() and class_implements() to find all classes that implement ObjectEncryptionInterface. These classes are then provided as SSE options in the admin settings.
• Same as above, but use a composer autoloader.

Any other ideas? I'm happy to write this.

[marius-wieschollek]

I have added an implementation of this in the PR above.
Instead of implementing the entire encryption, you only need to implement a key provider which receives the user id as an argument. An example implementation and the passwords app build with the feature are linked in the PR.

With this implementation, the third party app only needs to provide the secret key for the given user. This reduces the effort to implement the feature while it also gives the passwords app the option to do some quality check on the key itself and insure that it is sufficient for encryption.
I don't think there is a need to make the encryption method configurable in the admin settings. If there is more than one key source, this implementation leaves the selection of the right key for the user to the third party app. If there is any configuration needed, the third party app can take care of that.
This approach also ensures that the encryption still lives up to the expectations of the users. Requiring the third party app developer to implement the encryption themselves would increase the risk of badly implemented encryption methods or any corporate solutions where the encryption is weakened on purpose.
This approach also ensures that passwords using a third party key are properly marked and users can see that a third party key was used for SSE in the password detail view.

[marius-wieschollek]

Any update here? otherwise i will close this as abandoned.

[summersab]

Sorry for never providing feedback. Your implementation works wonderfully.

A few months ago, I was involved with a PR that was merged into the Nextcloud server code. It adds support for SSO user secrets in NC's authentication backend: nextcloud/server#27929

Your SSEv3 code adds support for this feature. Now that SSO user secrets are part of the NC core, I wondered if you would be willing to merge this code with the master branch. I would love to have this available in a version of Passwords that is compatible with NC 25.

Thanks, @marius-wieschollek!

[marius-wieschollek]

You may need to update your implementation for the final release.
The documentation with examples can be found here: https://git.mdns.eu/nextcloud/passwords/-/wikis/Developers/Encryption/SSEv3Encryption

[summersab]

Excellent documentation - thank you. This note stood out to me, though:

Your provider must be able to provide the key for a user even when the user is currently not logged in.

TL;DR:
When a user shares a password, SSEv3 encryption should be removed and SSEv2 should be applied. This way, shared passwords will be available when the password owner is not logged in. Background jobs are a different story, but this is basically how NC handles shared files with per-user secrets.

---

I will need to test out features like password sharing and may submit a PR or two. The IProvideUserSecretBackend class I mentioned (PR nextcloud/server#27929) is intended to be used under these conditions:

1. Server-side encryption is enabled
2. The master key is disabled and per-user encryption keys are used (occ encryption:disable-master-key)
3. A SSO IdP (such as Keycloak) is used for user authentication
4. The SSO IdP provides a custom user secret for decrypting user keys

User secrets from a SSO IdP are only available when a user is logged in. IdPs do not "provide" user secrets without users being authenticated.

As an example, this is how NC handles file sharing when IProvideUserSecretBackend is used. NC uses multiKeyEncrypt with a share key so a shared file can be accessed when the file owner is not logged in. Basically, a shared file is treated as if only the first condition is true. The user secret is no longer required to access the file, and standard encryption is used.

Similarly, when a user shares a password, SSEv3 encryption should be removed and SSEv2 should be applied. This way, shared passwords will be available when the password owner is not logged in.

Handling background jobs is a different discussion. I have a . . . "creative" solution for that problem involving a Node.js websocket server running beside NC. That is well beyond the scope of the Passwords app, though.

I hope that all made sense. Also, my apologies if I explained things that you already understood. I just wanted to be thorough.