google-drive-sync
google-drive-sync copied to clipboard
walterpg
Sharing Keep Pass file via Google Drive between people.
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
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
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? Cheers & Thanks
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 [email protected] 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 https://github.com/walterpg/google-drive-sync/issues/21#issuecomment-720020655, 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:
- The currently open, plugin-enabled database may have two mutually exclusive "modes" with respect to the plugin: shared and private.
- Private mode is distinguished by the presence of any Drive credential information in any plugin configuration entries in the database.
- Private mode is equivalent to the current plugin release's mechanics with one exception: the plugin refuses to sync when the target Drive file is shared with other Drive accounts.
- To enable shared mode, all plugin metadata that includes Drive credentials must be removed from the database.
- In shared mode, the target Drive file may be shared with other Drive accounts, and the plugin will allow sync ops.
- Because no credential data is present in shared mode, the user will be required to authenticate and authorize, via Google Sign On, once per KeePass session in which plugin sync commands are invoked.
Shared mode is not the most pleasant user experience; I wouldn't want to use it:
- Sign on to Windows.
- Sign into the KeePass database.
- Sign on to Drive.
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 [email protected] 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 https://github.com/walterpg/google-drive-sync/issues/21#issuecomment-720024589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHSKIIURJQO3N3OZVNJT73SNTOXJANCNFSM4S37IHMA .
-- James Fowler/方志宇 [email protected] [email protected] Public Key: https://sites.google.com/site/poorpermissions/pk/fowler_publickey?attredirects=0&d=1 http://rootless.googlepages.com/fowler_publickey
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 [email protected] 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 https://github.com/walterpg/google-drive-sync/issues/21#issuecomment-720164196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHSKIJBEYWNUQA37WZBUN3SNXQ3VANCNFSM4S37IHMA .
-- James Fowler/方志宇 [email protected] [email protected] Public Key: https://sites.google.com/site/poorpermissions/pk/fowler_publickey?attredirects=0&d=1 http://rootless.googlepages.com/fowler_publickey
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.
Google Drive now has symlinks which provides a fairly clean solution for sharing a database between two or more users without sharing google credentials:
- Bob (owner) creates a folder "f" in his drive and uploads the database "db.kdbx" into the folder
- Bob shares the folder with Alice for read and write (Editor)
- Alice creates a folder "f" in her drive
- Alice creates a symlink in folder "f" to the shared "db.kdbx"
- Both use "f" as the folder name in the KPSync configuration
- Sync works
