The excellent Keeweb project includes built-in support for syncing your password database file to various could-based sync services:
It would be awesome if similar functionality were built into KeepassX. It's nice not to have to run a sync service all the time when all you need to sync is your password database file.
I personally think this is outside the scope of this project, but would use it... I am :confused:
I've already seen Keeweb (and I have some security concern about it.)
KeePass is born as an offline password manager.
KeePassX follows this belief and have zero networking code in it.
KeePassXR have the support for keepasshttp (that is disabled by default and IMO me needs an option disable it at compile time)
Personally I don't see the needs to insert such a feature when you can simply save the database file in the Dropbox/GDrive/OneDrive/Syncthing folder and they take care of the syncing (with versioning, conflict-resolve, etc)
I too agree, I don't see the need for cloud integration when you can simply drop the whole database in your Dropbox folder and you are good to go. I also feel that adding a lot of code that interacts with the outside world has the potential to become a security concern eventually, so the more isolated the program is and the less it interacts with the rest of the system the better.
People who choose an offline password manager do so because they are concerned about security, if you want cloud integration there are better solutions than trying to make KeePassX something that never was. I think the focus of the project should be first on building the most secure offline password manager and then everything else.
I also agree that there should be an option to disable keepasshttp at compile time, I'm pretty sure that there are quite a few people (or distros) that might feel a bit uneasy about that feature.
Please open a separate issue about disabling the http support (either at runtime or compile time). Im closing this one because it is outside the projects scope.
This is quite sad. I thought that this project will bring Keepass to 2016, but nope. It will need one more reboot them most probably.
I am using Enpass now and I am thinking to switch to Keepass*, but what I am missing is syncing with WebDAV to have actual version of my database everywhere (even on computers, where I don't have cloud client (dropbox, owncloud, whatever) installed.
This issue I think can be opened and maybe someone will create PR to implement this? ;-)
@ronnicek I don't agree with your opinion about bring KeePass to 2016.
WebDav from wikipedia
WebDAV is often associated with drive mapping. Windows, Mac and Linux support mapping a WebDAV folder as a network drive.
So whats the problem with syncing the file as a network drive and then open them with KeePassXC ?
We are also working on an auto-update feature so changes to the synced file will be auto-reloaded.
Inserting a WebDav (or Dropbox, GDrive, etc) client will add "useless" code to KeePass.
There are thousand of client that already do that specifically, why insert a client in a password manager?
I think KISS
If you can tell me a real argument (and if lot of user approve this) I can consider adding it, but don't tell me that we need to "bring KeePass to 2016" by inserting a WebDav client
And when you are on computer when you can't install dropbox, gdrive, you can't map webdav thru normal system what should I do? Upload that file everytime I am leaving to my owncloud?
I'm not sure if this is a strong or even a valid point, but there is at least one common situation that happened to me multiple times and I don't know how it would be resolved by simply putting the database on Dropbox or something similar.
Sometimes I create and store passwords that are not necessarily login related and I not always have an internet connection when I do so. This has happened in 2 devices independently more than once. 1Password has resolved later this without bother. It successfully noticed that the database in one of the devices had a password not present in the other and vice-versa and merged both generating a database that had the 2 passwords.
I think, but I can't be sure, that this situation would not be resolved in such a smooth way if this kind of checking is not built into the software. And I think that the biggest driver for such implementing such a checking is some kind of synchronisation mechanism.
I don't mind exactly what kind of mechanism. Indeed it would be interesting to discuss the pros and cons of the multiple solutions available to achieve this synchronization (dropbox, owncloud, bittorrent sync, etc), but I think at least a smart algorithm for checking discrepancies across databases and merging them would be necessary.
I am very interested in changing from 1Password to a open source cross-platform solution, but now our lives commonly spans multiple devices: personal and work desktop, laptop, tablet, phone, etc. I think that it is very important to find a safe but convenient solution to keep life synchronised across these devices and that today this is an essential feature, not a luxury.
There is an autoreload and merge feature built into keepassxc
Well, if that's the case I will start trying it out. Sounds like it could be a suitable replacement.
I want to migrate form lastpass to a self hosted solution for my passwords as well but the problems @deOliveira-R mentioned making it hard (or even impossible) for me to do so.
I have a setup with two computers and a mobile device. I would like to see a solution where a can work on both machines (mobile is read only), add new passwords and sync these changes without generating conflicts. I don't see how this can work with the current feature set in combination with an external sync solution.
I would like to see an explanation of their setup from the people that say "just put it in your sync folder and it works". What sync tool do you guys use that handles this in a good way?
A solution would need to check the cloud, get the file, merge the changes back to the local file and reupload it to make sure all files are in sync without loosing data. As far as i can tell, the "autoreload and merge" feature can only handle a small part of this update chain.
Do i miss something obvious here?
Greetings,
Andy
I will tell my environment and how I use it.
I have 2 PC and 1 mobile device, I use Syncthing for syncing the kdbx file across those 3 device.
One of the PC is my main device where I do most of the changes on the kdbx, those changes are propagated to the other device by syncing the kdbx file, then the autoreload-and-merge on my other PC takes the changes.
On my phone since I can't use KeePassXC directly I close the kdbx every time and reopen it so I don't need the autoreload-and-merge feature (everytime it will open the latest version). If I make some changes on the phone, Syncthing will send the file to the PC that will merge back and so on.
Note: With Syncthing you can use File Versioning so if something go wrong you can recover an older version of your file.
Anyway. Adding a "cloud-sync client" is just something as "upload that specific file to dropbox/box/oneDrive using that specific protocol".
This is essentially the same thing as using the Dropbox official client.
The matter here is that we prefer not having such network code so if you want to sync a file you need to use another specific client.
Hi @TheZ3ro ,
thx for sharing your setup, I can see how that works for you. Sadly i cannot use Syncthing. I need a server based solution. Dropbox would work as well i guess cause they have a good linux client, i have to look into that. Initially i wanted to use Google Drive cause i use it for other tasks anyway but they have no official linux client and all the other solution don't offer a real sync mode or are commercial.
I still would prefer an integrated solution but i can see the arguments against it.
@sxe Yes, GoogleDrive doesn't have an official linux client sadly.
You can use Dropbox, it will works fine like Syncthing. :+1:
there are various Google Drive plugins for Linux file managers. I use one myself in Dolphin.
For syncing my kdbx file I use Nextcloud and it works fine. Since I'm never editing the file at the same time from two different locations, I have never experienced any conflicts.
One of the PC is my main device where I do most of the changes on the kdbx, those changes are propagated to the other device by syncing the kdbx file, then the autoreload-and-merge on my other PC takes the changes.
autoreload-and-merge merges changes when the file is changed when changed on disk and the app is open, if it is changed on disk on other times data loss might occur.
as shown on #822, which is easily reproducible, shows a real world example of data loss in this case(which i ran into, sadly...), and would not be fixable with many of the cloud storage solutions available, including dropbox, google drive, and onedrive.
on syncthing this would indeed be fixable if you're using file versioning, by simply merging with the last version of the file in syncthing's history.
there's a reason they have a master-local synchronization setup documented on the keepass site to prevent data loss
http://keepass.info/help/kb/trigger_examples.html#dbsync
i'm not saying it's necessary to implement a full synchronization implementation for every major cloud provider, however i would definitely like to have such a synchronization scheme possible in keepassXC (or implement it into keepassxc by using a separate version of the DB internally in the application (stored somewhere else where it should not be accessed by any other program/user) and syncing to the version stored on disk) to protect against data loss.
I want cloud synchronization.
Why?
Simplicity for the user.
I've got multiple devices, and I don't want the extra hassles of configuring dropbox. I'm not even familiar with how to do that on my iPhone since I have icloud. I also have several Windows machine, and several Linux machines. I also have machines at work that I'd like to keep installed apps to a minimum, and prefer portable apps.
So far I like Enpass as an alternative.
@sxe Yes, GoogleDrive doesn't have an official linux client sadly.
You can use Dropbox, it will works fine like Syncthing.
@TheZ3ro Another issue for Dropbox users is that from March Dropbox introduced a 3 devices limit on client synchronization.
Personally I don't see the needs to insert such a feature when you can simply save the database file in the Dropbox/GDrive/OneDrive/Syncthing folder and they take care of the syncing (with versioning, conflict-resolve, etc)
Conflict resolution is exactly the reason why most other KeePass applications support cloud sync. Natively or via a plugin. If we leave conflict resolution to the OS then the newest file wins. If changes were made from different sources between the last sync then changes are lost!
This is not entirely true. Integrating cloud file access directly in the application does not solve conflicts. You still need to have a robust merge strategy to resolve differences and apply them. We do this already by checking the on-disk version of a file with the currently open database before saving.
Most helpful comment
autoreload-and-merge merges changes when the file is changed when changed on disk and the app is open, if it is changed on disk on other times data loss might occur.
as shown on #822, which is easily reproducible, shows a real world example of data loss in this case(which i ran into, sadly...), and would not be fixable with many of the cloud storage solutions available, including dropbox, google drive, and onedrive.
on syncthing this would indeed be fixable if you're using file versioning, by simply merging with the last version of the file in syncthing's history.
there's a reason they have a master-local synchronization setup documented on the keepass site to prevent data loss
http://keepass.info/help/kb/trigger_examples.html#dbsync
i'm not saying it's necessary to implement a full synchronization implementation for every major cloud provider, however i would definitely like to have such a synchronization scheme possible in keepassXC (or implement it into keepassxc by using a separate version of the DB internally in the application (stored somewhere else where it should not be accessed by any other program/user) and syncing to the version stored on disk) to protect against data loss.