search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
21.34k stars 1.47k forks source link

Improved KeeShare share configuration #2747

Open ckieschnick opened 5 years ago

ckieschnick commented 5 years ago

Recently we did some internal discussions how to improve the KeeShare feature. We determined that it may be good to extend the feature to allow more secure or custom configurations for the shares.

Desired Behavior

Shares should be analog to a standard database - the should be configurable with a password, a key file, encryption algorithm, key derivation algorithm with the corresponding settings. It may even be desired to use the database description or similar.

Possible Solution

Adapt the database creation wizard or duplicate the needed functionality to allow the configuration of shares. Introduce the needed attributes to store the settings within the references.

Context

Considering the fact that shares may reside on inherently insecure locations which may allow an attack to use brute force, it would be better to let the user choose the security.

droidmonkey commented 5 years ago

With the unsigned share you can simply create a database and use as normal. This works great 👍. An option at the end of create a database wizard to "sign and share" would be easy to add and support this feature without any additional code in KeeShare.

Or even at the beginning of the wizard you can choose to create a signed share which would restrict you to password only.

ckieschnick commented 5 years ago

Currently the sharing does overwrite the container with each export without reading from the file, so I don't think the creation of the database before works. Overwriting allows us to increase the security of a container even after first creation as long as all clients which may read the container support the needed settings.

droidmonkey commented 5 years ago

Yes, the export feature is a bit misleading because its more like "overwrite". Some may think it is export and merge.

ckieschnick commented 5 years ago

Why do you think an export would do an implicit merge in the share container? I'm open for suggestions to remove this hidden meaning.

droidmonkey commented 5 years ago

I don't think that, per say, but other people may. You are saying "The things I put in this share will be moved to an external database" when you say export.

I could recommend splitting export into two modes: Export (merge) and Export (overwrite) to be explicit

ckieschnick commented 5 years ago

I think we are currently mixing two different things. KeeShare does need exports and imports to work correctly - these are designed in a simple way to allow for a simple merge algorithm. We should not use the export part of KeeShare for other features directly, but create a similar but independent feature. This can take the role of Export (merge) with any additional logic required. The user does not need to know how the sharing works internally (in my opinion opening the share file is more a positive side effect than a requirement). Furthermore, separating the feature, we do not need introduce complex behavior into the sharing. If you agree, we should move the discussion about this Export (merge) into another ticket since it would be out of scope to this ticket.

droidmonkey commented 5 years ago

Yes I agree this is a separate feature (I was abusing the "export" term). Let's keep this issue focused on how to better initiate a new share with an uninformed user.

dmrzzz commented 5 years ago

If I'm understanding this proposal correctly, it would be amazing for people like me who just want to replicate a kdbx across many devices, and currently rely on https://keepass.info/help/kb/trigger_examples.html#dbsync to mitigate the potential for data loss in case something goes horribly wrong with cloud sync.

AFAICT, KeeShare Synchronize very nearly does what I want, except that I use a composed master key (password + key file) which is not currently supported by KeeShare as discussed in https://github.com/keepassxreboot/keepassxc/issues/90#issuecomment-462118659. It's true that using a different and much longer password could be made equivalently secure, but it's a lot less convenient; for simplicity (and for Keepass2Android) I want my cloud kdbx to have exactly the same master key as my local kdbx.

Highly desirable in addition would be a checkbox to automatically use the same master key for KeeShare (without having to input it an additional time).

Finally, once a new best practice becomes available, it would be great to document it in https://keepassxc.org/docs/#faq-cloudsync (right now the FAQ suggests simply storing your KeePassXC database inside your shared cloud folder, which will work most of the time but has some spectacularly catastrophic failure modes).

droidmonkey commented 5 years ago

Can you explain the failure modes you suspect could occur? I use the "simple cloud sync" since I started KeePassXC and have never had an issue.

dmrzzz commented 5 years ago

@droidmonkey happy to! Please note: I'm not saying that simple cloud sync has a high probability of failure, but I take a somewhat paranoid view since my kdbx is the most important single data file I have.

  1. Somehow a corrupted (unreadable) version of the file gets pushed into cloud sync; now all my devices have the corrupted file and I can't read my passwords! This could be caused by a malicious compromise of one device (e.g. ransomware), by random bit rot / cosmic rays on one device, by a bug in the cloud sync software, by a malicious compromise of my cloud sync account, or by some kind of bone-headed operator "oops" on my part.

  2. Somehow the kdbx file gets deleted from cloud sync; now it's gone from all my devices and I can't read my password! (same possible causes as above, give or take)

Of course those failure modes can and should be mitigated by other forms of backup, but other backups might be a lot more inconvenient to access (especially if e.g. I use a cloud backup provider and my password for that account is stored in the kdbx). The KeePass trigger model keeps an extra copy of the file which is never directly modified by cloud sync, so no matter what might happen to device A and/or my entire cloud sync provider, I have an intact recent copy of my kdbx on devices B and C that I can conveniently use to access my passwords (even before resorting to full-fledged backup recovery options).

  1. On device A I modify one entry X, and a little while later on device B I modify another entry Y. But for some reason (network offline, service offline, who knows?) my cloud sync was lagging behind, so the version I edit and then save on device B doesn't already include change X. Now two versions of the file exist: one with change X, one with change Y. No version of the file exists with both X+Y. My kdbx contains hundreds of entries, so in human terms I'll never notice anything is amiss until I actually need to use one of the changed passwords (which could be months from now).

On its best day cloud sync can't resolve this problem; it doesn't know how to merge kdbx files. Best case scenario: cloud sync does the only thing it can do, which is alert me to the fact that a file conflict exists and provide me with both versions for manual reconciliation. I must then perform two one-way merges in KeePassXC to generate a new file version which definitely contains both changes, and then make sure that version goes back into cloud sync. Worst case scenario: the cloud sync software hits some sort of edge-case bug and doesn't alert me to the conflict, so one version or the other "wins" and one of my changes is silently lost (even on the device where I made it). Six months later I need the lost password to log in to an important but rarely-accessed account, and I don't have it. Even my other forms of backup may not have it by that time, since it only ever existed for less than a day.

In the KeePass trigger model, I won't permanently lose either of my changes no matter what the cloud sync does, and eventual consistency is achieved without any special action on my part (whether cloud sync detects the conflict or not). Change X still exists in local copy A, so subsequent two-way merges on device A ensure that change X makes it into the cloud copy, and also that change Y (once seen in the cloud copy) makes it into local copy A. Similarly, subsequent two-way merges on device B ensure that change Y makes it into the cloud copy, and that change X (once seen in the cloud copy) makes it into local copy B.

I already use KeePassXC on my secondary Mac, and hope someday to use it on my primary linux workstations too (replacing Mono+KeePass), but Mono functions just well enough that I don't want to give up such an elegant best practice for taking advantage of cloud sync without having to fully trust cloud sync.

seafox commented 5 years ago

The ability to have master - local dbs autosync functionality described in https://keepass.info/help/kb/trigger_examples.html#dbsync is essential. Now with v2.5.0 - how to achieve that? Is there an ability to specify the master db path, protocol and net share credentials (samba, sftp, etc.) within opened local db? Maybe there is a need for a new AutoSync named group that would perform sync twice - import on opening and export/import on closing the local db?

droidmonkey commented 5 years ago

Syncing with an arbitrary database is not KeeShare. KeeShare is intended for persistent sync of a collection of entries that are shared between two KDBX files.

seafox commented 5 years ago

Syncing with an arbitrary database is not KeeShare. KeeShare is intended for persistent sync of a collection of entries that are shared between two KDBX files.

This thread shows terminological inconsistency even within the dev team. Whatever. I'm observing a kind of team avoidance to send direct clues how to mimic similar to twice referenced here KeePass sync functionality. Maybe even without exact hash-by-hash copies of both resulting db files. But with ability to avoid spilling/leaking a master copy kdbx file name, location and the net share credentials outside the locally opened kdbx file (like into KPXC settings/config file that is plain open). Hope that's clear description of intent required to migrate from KeePass + mono. Thanks!

droidmonkey commented 5 years ago

I understand what you are looking for. It's really a bi-directional merge. Currently you can achieve that using KeeShare, but it's not a File -> Sync with other DB... Type of feature. We also do not support directly accessing remote databases, so you'd need to mount your remote storage to a local directory.

seafox commented 5 years ago

... We also do not support directly accessing remote databases, so you'd need to mount your remote storage to a local directory.

Okay, do you support executable console commands within KPXC to make such mount operations on-the-fly, with params (command line), made from (protected) fields within local db file? Or, alternatively, via another plugin for remote access like smb:// sftp:// etc.?

droidmonkey commented 5 years ago

No. There is another issue already to track remote database access support.

seafox commented 5 years ago

No. There is another issue already to track remote database access support.

Bad, as so far this remains as a show stopper! #1775 is still nowhere near completion (in v3.x.x?), even samba #803 is still problematic. So basically, unless KPXC supports either A. triggers with scripts with ability to fetch params from db fields, like onDbOpening, onDbOpened, onDbClosing, onDbClosed or B. plugins for remote access like sftp:// smb:// to sync onOpen and onClose.

At the very least, some automation for custom scripts like this, but executed from inside successfully opened db file.

Can you give an estimation whether the feature(s) would be considered and implemented at all, which one and approx. time span to check for?

Wirone commented 3 years ago

Right now I am struggling to configure KeeShare so my passwords are synced between 2 computers (2 separate databases). What I did:

It somehow works, but:

Am I doing something wrong?

droidmonkey commented 3 years ago

You are hitting the known bugs of keeshare, unfortunately. The ui freezing is probably because you have your encryption settings set to high causing large delay in saving.

AxOptim-Samuel-Linares commented 1 year ago

hello to avoid losing entries when sharing databases, could it be possible to create a group history, to be able to save an re-create the previously saved data ?