Synchronisation with or direct use of a KeePass KDBX database stored in Nextcloud files

[Freeedim]

Current Status Currently, KeePass databases can be imported in NC Passwords after having been exported in a CSV file from the KeePass application. But it seems Passwords is not able to directly handle a KDBX file. Therefore a user cannot work easily on a single credential database with both Passwords and KeePass or KeePassXC. Put shorter: there is no straightforward interoperability.

Feature Description I would love to have a field where I can indicate the KDBX file(s) that are in my Nextcloud Files, and a button to open it in the web app. It would then ask for the KDBX file's password and/or file key (and/or ideally my YubiKey), then present my KDBX's content as any regular Passwords content.

In case the sharing feature is too complicated or impossible to manage with a KDBX file's entries, instead of making Passwords deal directly with the KDBX file, there might be a regular Passwords folder that is kept synchronised with the KDBX file, with read-write access, as I think the KeePass/KDBX API is free.

Additional context In my case, interoperability would be key to adoption, and Passwords great features and great integration with Nextcloud makes me want to adopt it. But I don't feel like completely stopping to use KeePassXC, KeePassDX and stopping to be able to collaborate with some Windows KeePass users.

[marius-wieschollek]

Duplicate of https://github.com/marius-wieschollek/passwords/issues/347

Here is why i'm not integrating KeePass: https://help.nextcloud.com/t/integration-with-keepass/107597/2?u=mdw

Maybe someone could write a sync app that synchronizes between the two apps. But even then there would be drawbacks.

• The app would need access to the keepass file password and it would need the E2E password for the passwords app (if e2e is enabled).
  • For a regular automatic sync, both passwords would have to be stored in a decryptable way on the server, essentially bypassing the E2E for both apps.
  • For a semi automatic sync, the passwords could be stored in the passwords app and a sync could run automatically when you open the app.
• And then there is the synchronization itself for which the sync app would have to keep track of which password is synced to which in the other app. The passwords app does have ids for every password so the best way would probably be to just store that as a custom field in the keepass database.
• The sync app would also have to handle different features, e.g. otp, attachments, "colors" and icons exist only in keepass, while custom field types, markdown notes, favorites and sharing only exist in passwords

If you, @stondino00 and maybe some of the others who asked for keepass integration would be interested in this, maybe i could give it a go later this year. Otherwise i would suggest the keepassweb app for nextcloud or the export script from monperrus

[thrdroom]

Otherwise i would suggest the keepassweb app for nextcloud

Keepassweb and Keeweb sadly are no viable options any longer.

As mentioned in this issue from the Nextcloud Keeweb repo, the upstream project Keepassweb is searching for a new maintainer for quite some time now until then, both apps are basically EOL cause KeeWeb can not be build any longer atm. Both projects seems to be pretty much dead currently.

Maybe @marius-wieschollek would be interested in maintaining Keepassweb and Keeweb instead of NC passwords, as the keepass ecosystem is more widely spread and has more features compared to the much smaller NC passwords. I never understood why the wheel has to be reinvented over and over again instead of joining forces for the same goals.

[marius-wieschollek]

I'm not going to maintain Keepassweb. It can't do what i want and i don't have time for it.

But also my suggested semi automatic sync would require keepassweb at least as a library, so that sucks for this idea too. he library i found for a fully automatic server-side sync only supports kdbx until version 2. Maybe keepassxc-cli could be used there?

But that also sums up my experience with the keepass "ecosystem". There are tons of different app in various states of abandonment with different features (and export bugs) and that also don't seem to be that compatible with each other.

[Freeedim]

In the case of Passwords directly handling KDBX files, I think the arguments about Passwords needing to access the KDBX password might be addressed by asking the password to the user, like the e2e password in Passwords.

About features mismatch, I don't know as I am still only discovering Passwords.

The main point for me would be to be able to set sharing and access rights to each KDBX entry, that would then be served by Passwords. KDBX sharing is not as flexible and the KeeShare scheme allows receivers to access my passwords with a very weak password without me having control on that.

[marius-wieschollek]

In the case of Passwords directly handling KDBX files, I think the arguments about Passwords needing to access the KDBX password might be addressed by asking the password to the user, like the e2e password in Passwords.

It's not that easy. You also need to do something with the password. Sending it to the server would make things easier for app & extension developers, but most users will be pretty (negatively) surprised if they found out their password is doing a round trip trough the internet when they log in.

If the KDBX access is not managed by the server, every client would have to implement handling KDBX files. That will be confusing for users since some clients may be able to read their Keepass data and some others won't. Integrating KDBX files also will make the app less user friendly since suddenly some features will be available for some passwords while others won't be. Like you will be able to share internal passwords, but not Keepass passwords. In order to provide a uniform user experience, the app will have to do a constant merging of passwords an Keepass data, like matching up folder structures and tags etc. That will increase development efforts and definitely cause constant merging errors. If we don't merge, it will just feel like two apps under the same hood. A Keepass integration will also enable users to do things that the app doesn't allow them to do, like resharing passwords where they weren't allowed to reshare.

Trust me when i say this, i have some experience with this. A KDBX integration will not be a cool extension of the passwords app, it will be the end of it and the app will become abandonware just like all the other Keepass apps. The few people who use this feature will have a frustrating and bad experience that is incomplete and constantly doesn't work and the majority of the users will just get tons of bugs out of this.

Keepass and Passwords are built on completely incompatible architectures. Keepass is a file based password manager, Passwords is a centralized server based password manager. This is like asking Wordpress to add a Word integration since you really like those macros and want to keep the files you have.

The sync option mentioned above is the "best" solution i can think of since it keeps both separate and acts as a middleware.

There will never be a Keepass integration.

[thrdroom]

I guess you are right. From now on it's either local keepass, nextcloud passwords or bitwarden.

[Freeedim]

Ok I am convinced now.

I guess my main drive was:

• the hope of benefitting of the same level of security as e2e encryption (especially against the administrators of the NC instance) while being able to share a password with other NC users, and
• having my KeePass entries in Passwords without uploading plaintext passwords in a CSV file.

I am not a specialist but those two things seem a bit scary to me.

[marius-wieschollek]

I should probably point out this part of the F.A.Q about E2E in Nextcloud. Any E2E on Websites (like your Nextcloud) can be bypassed by whoever controls the code of that website. So your admins, any app developer of any app installed, someone intercepting not HTTPS encrypted traffic or an attacker with access to the server can just simply add a keylogger to the website that steals your E2E password.

If you don't trust your Nextcloud admins (or their ability to keep the server safe), you can't use that Nextcloud in any safe way.

Additionally, the Passwords app does not upload any files in the import to the server. The file data is processed locally and the resulting passwords, folders and tags are uploaded to the server with your default encryption method.

[sunjam]

If you don't trust your Nextcloud admins (or their ability to keep the server safe), you can't use that Nextcloud in any safe way.

This is the literal reason to use Keepass itself as a self contained app. If someone cares about this they can avoid depending on any server app and instead use their client devices. Worth noting, no one is forcing anyone to use a web app for their passwords if they do not need it.

If you prefer trusting the web app, this Passwords app is a nice option. Passwords and Keepass will always provide different implementations. :)

[Freeedim]

Any E2E on Websites (like your Nextcloud) can be bypassed by whoever controls the code of that website. So your admins, any app developer of any app installed, someone intercepting not HTTPS encrypted traffic or an attacker with access to the server can just simply add a keylogger to the website that steals your E2E password.

@marius-wieschollek I think using open-source software mitigates what you describe, although I am conscious there are some residual risks. I guess (hope) there are some hashing/signature checks when one installs a Nextcloud app from within the web app, in order to ensure that the source code that is released and auditable is the one that is compiled and plugged-in the Nextcloud Hub.

If it is actually the case and if, like in my use case, the remote system (hardware + OS) is rented and maintained by skilled and paranoid third-parties, I think it becomes quite hard to insert a keylogger in the delivered javascript. Thus, E2E becomes reasonably trustworthy.

Additionally, the Passwords app does not upload any files in the import to the server. The file data is processed locally and the resulting passwords, folders and tags are uploaded to the server with your default encryption method.

I had not realised this, so thanks for the clarification. Very good to know this.

@sunjam: Yes, I agree. but I was so blown by the password sharing UX in Passwords, that I guess I have immediately wished I had it with E2E and/or my existing KDBX files. I believe in my use case (basically, extremely sensitive data about extremely vulnerable people, that need to be shared across many legitimate users, but kept extremely secured against any other people, with a budget approaching zero) would have found the miraculous solution. Right now, I relies on scripts, vaults and free tools like KeePass, gocryptfs/cppcryptfs and VeraCrypt; it works well but it's quite cumbersome to install and configure on each new user's computer.

[marius-wieschollek]

@Freeedim Apps are usually signed, some apps (like this one) also provide hashes for every file and nextcloud can notify admins about changes made to an installed app. However, Nextcloud doesn't require verifiable builds (unlike Mozilla), so you can't know for sure that the open source code is the one that has been compiled into the app you get. With an ecosystem like NPM (for Javascript), even the author won't be able to tell you what code exactly runs in your browser at the end.

The most secure way to use E2E is with the apps that are listed in the apps section. These can't be modified by anyone on the server.