Sharing Keep Pass file via Google Drive between people. #21
Comments
|
Hi, your idea is a good one. I'll admit to being a novice in multi-user/sharing scenarios with Drive. So I want to make sure I understand the concept of your request. Could you describe with as much detail as possible the use case you have in mind? In the simple file sharing scheme that I'm familiar with, the file Owner shares the file with one or more other target Drive account users, and the file appears in those users' "Shared with me" virtual folder. In order for the target users to sync with this file, the owner must grant Edit permission to the file. This appears to work as expected with the current plugin release OK, with a caveat. It is true that a target user cannot specify a Target Folder to the shared file, since it is in "Shared with me". But sync is possible if you don't specify a Target Folder. But let's assume the target user wants to get organized and use the Target Folder feature with a shared file. They can, as far as I know, create a Drive Shortcut to the file, and place that shortcut in one of their own folders. So would the enhancement in #20 suffice for this feature request? |
|
Every thing you say is correct, but I think your testing as yourself in both cases. I assume every file shared should have a unique path. And this path would need to be enter into the plugin. (or username and file name ????) I suppose you could display this path in the plugin, so that people could copy it and email it to other people for them to set in the plugin.. Not sure how the iPhone/Android versions of keePass would go or implement this. e.g. https://play.google.com/store/apps/details?id=keepass2android.keepass2android Maybe you both can work out a solution. Thanks |
|
@PhilippC might have some thoughts |
|
Thanks for helping me think through this. The fact is, the current plugin mechanics cannot securely support a scenario where the database file is shared among multiple Drive accounts. The problem is this: the database includes the sync configuration details, and, as per "recommended usage", usually the owner's Drive credential. But even if a prudent owner's Drive credential is not in the configuration entry, the authorization token saved in the KP entry would be used by all shared users with the authority of the last user to authorize the plugin. This is a Bad Thing in general, but particularly if the database is shared read-only. So as I mentioned above, "it works", but the owner's and shared user's Drive credentials are exposed to everyone the database is shared with. The database's "master password" credential saves this from being a total catastrophe (don't share that!), but the issue must be addressed. For now, I Highly Recommend that all Drive sharing features be avoided with files accessed by the plugin. Shared files will be excluded from use in the next release, and thereafter until there is a secure solution. |
|
@walterpg I assume that because your storing the Refresh Token for the current user. Which is the same as the users password? So for people to share this, the Refresh Token etc would need to be stored outside of the DB. And I assume @PhilippC not trying sharing the DB with other people as well. What happens when you copy the DB file to another computer assume it would just use the same username and refresh token? I suspect your tell me the plugin system/api does not support storing the Refresh Token outside of the DB safely? |
|
I do this all of the time, with multiple databases and it works very well.
The token is stored in the database.
Thank you.
…On Sat, Oct 31, 2020, 20:24 Damon Atkins ***@***.***> wrote:
@walterpg <https://github.com/walterpg> I assume that because your
storing the Refresh Token for the current user. Which is the same as the
users password? So for people to share this, the Refresh Token etc would
need to be stored outside of the DB. And I assume @PhilippC
<https://github.com/PhilippC> not trying sharing the DB with other people
as well.
What happens when you copy the DB file to another computer assume it would
just use the same username and refresh token?
I suspect your tell me the plugin system/api does not support storing the
Refresh Token outside the the KB safely?
Cheers & Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSKIIA4SHXZVQCWTATNUTSNTIHFANCNFSM4S37IHMA>
.
|
|
Sure, it works. But sharing an authorization token with other users is in no way secure. Especially a token that grants full read/write access to a Drive account that isn't yours. |
|
A proposal:
Shared mode is not the most pleasant user experience; I wouldn't want to use it:
That aside, the other issues to be resolved are what to do about non-credential config (Target Folder) and then there's always the KP portable installation issue. Perhaps Drive's application storage feature could be useful, but you still have to sign on to get there. |
|
Why would anyone ever want to give someone else access to a database full
of authentication information if they aren't comfortable having them
read/write to a Drive account?
It is also pretty easy to set up an account used just for synchronization.
Even if you reuse this for other Keepass databases, the databases are all
encrypted.
To change this behaviour would fundamentally break the utility of Keepass
database synchronization for all of my use cases.
For all of my use cases, the point is to not require additional
authentication or authorization steps for users, while still providing
secure synchronization of the encrypted database.
…On Sat, Oct 31, 2020 at 9:20 PM Walter Goodwin ***@***.***> wrote:
Sure, it *works*. But sharing an authorization token with other users is
in no way secure. Especially a token that grants full read/write access to
a Drive account that isn't yours.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSKIIURJQO3N3OZVNJT73SNTOXJANCNFSM4S37IHMA>
.
|
|
As you say @rootless4real, it is pretty easy to set up an account used just for synchronization. This is a shared account. In that case all users sign into the same account, because, indeed, they all have access to the credentials, whether they are in token or user/password form. This is, ironically, "private mode" in the proposal (need better terminology here). Settling any TOS issues with multiple users signing on to a single, shared account is between you and Google. The trouble with the plugin starts when someone unwarily uses the Drive share feature to share the database file to/from multiple private Drive accounts. The sharer, and the group the database file is shared with, has an expectation of privacy and security here. Generally nobody would willingly share their private Drive account credentials, so they should not be placed in such a database. Even if the sharer is clever and removes the Drive user/password credential from the plugin's database entry, an authorization token will eventually be saved there. It might not be the sharer's token, btw. A nefarious user in the group could upload the database without the plugin, without storing a token, or even just deleting the one that is already there, then share the file. Whoever syncs first thereafter has their authorization token saved in the database. The token along with the plugin's OAuth creds provide full access to their Drive account. Anyone in the group could potentially be compromised this way. The plugin must not enable such exploits. A commercial solution might employ an online "secrets service" to render its OAuth credentials, thus leaving stored authorization tokens worthless outside of the app. Unfortunately this is not a viable option for an open source project. For the near future, use cases that depend on the current shared token scheme, could be allowed to use the personal OAuth credentials option as an adequate, unsecure workaround. As for a future enhancement to "shared mode": maintaining the single-sign on compromise with the Drive share feature could be accomplished by storing the authorization tokens outside of the database, on the local machine. Windows has some reasonable facilities for implementing app configuration databases that have been used in other plugins. |
|
Great explanation. Thank you for the clear outline. I agree it is a
difficult ask for an open source project, especially without making it
onerous for the end-user having to authenticate to multiple services before
accessing the database, as you outlined.
Thank you for your great work on updating this project and keeping syncing
alive for Keepass.
James
…On Sun, Nov 1, 2020 at 3:50 PM Walter Goodwin ***@***.***> wrote:
As you say @rootless4real <https://github.com/rootless4real>, it is
pretty easy to set up an account used just for synchronization. This is a *shared
account*. In that case all users sign into the same account, because,
indeed, they all have access to the credentials, whether they are in token
or user/password form. This is, ironically, "private mode" in the proposal
(need better terminology here). Settling any TOS issues with multiple users
signing on to a single, shared account is between you and Google.
The trouble with the plugin starts when someone unwarily uses the Drive
share feature to *share the database* file to/from multiple *private*
Drive accounts. The sharer, and the group the database file is shared with,
has an expectation of privacy and security here. Generally *nobody* would
willingly share their private Drive account credentials, so they should not
be placed in such a database.
Even if the sharer is clever and removes the Drive user/password
credential from the plugin's database entry, an authorization token will
eventually be saved there. It might not be the sharer's token, btw. A
nefarious user in the group could upload the database without the plugin,
without storing a token, or even just deleting the one that is already
there, then share the file. Whoever syncs first thereafter has their
authorization token saved in the database. The token along with the
plugin's OAuth creds provide full access to their Drive account. Anyone in
the group could potentially be compromised this way. The plugin must not
enable such exploits.
A commercial solution might employ an online "secrets service"
<https://azure.microsoft.com/en-us/services/key-vault> to render its
OAuth credentials, thus leaving stored authorization tokens worthless
outside of the app. Unfortunately this is not a viable option for an open
source project.
For the near future, use cases that depend on the current shared token
scheme, could be allowed to use the personal OAuth credentials option
<https://www.kpsync.org/usage/oauth> as an adequate, unsecure workaround.
As for a future enhancement to "shared mode": maintaining the single-sign
on compromise with the Drive share feature could be accomplished by storing
the authorization tokens outside of the database, on the local machine.
Windows has some reasonable facilities for implementing app configuration
databases that have been used in other plugins.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSKIJBEYWNUQA37WZBUN3SNXQ3VANCNFSM4S37IHMA>
.
|
|
There is also share by link, which could be read only (as you sill need the DB password), and you just prompt for credentials when writing. Would reduce the number of times a user is prompted. The request was not meant to discover an issue with the current implementation. I suppose people may not realise the significance of what is being store in the DB by the plugin so the syncing works. |
Also, migrate global config to JSON in a single KeePass config element. Also, upgrade to latest Google API packages. Devise a temporary workaround for the shared file use case for compatibility.
|
Google Drive now has symlinks which provides a fairly clean solution for sharing a database between two or more users without sharing google credentials:
|
Is your feature request related to a problem? Please describe.
Sharing Keep Pass file via Google Drive between people/accounts.
Describe the solution you'd like
Check in two locations for the file. Location as the owner and a location when the file is shared to other people.
Describe alternatives you've considered
None
Additional context
None
The text was updated successfully, but these errors were encountered: