Keepassdx: No support for OneDrive or Dropbox?

[KirkH420]

Add Web login support for Cloud services like OneDrive and Dropbox. I saw that I could use google drive, but I am working on getting away from using google software as much as possible.

KeepPass2Android isna good example of how this is done and it allows for one cloud saved keyfile to sync multiple password managers across several devices.

[J-Jamet]

There are several reasons why cloud code is not directly integrated into KeePassDX :

• OneDrive and Dropbox are not free software, and KeePassDX wants to stay under GPLv3 license.
• If I start to integrate connection code directly in the application, it will integrate all the APIs of all existing clouds to not favor one more than another (can do a lot of problems).
• With KeePass in connected mode, it will be necessary to put the Internet permissions, which will open security breaches.
• It does not respect the mode of encapsulation of Android applications. The phone's file manager should be the only one to access files (even remote)
• If OneDrive and DropBox have not correctly created their applications to be compatible with the file manager and URI links of the device, it's not the fault of KeePassDX. GoogleDrive is integrated with the default file manager and works.
• The application is still in beta and the synchronization must be created to retrieve the last partially updated data.

I've been thinking of creating another file manager application for this proprietary cloud API but I have to previously finish KeePassDX.
I do not prevent anyone from using non-free services, it's only a matter of trust, but I personally trust only the servers I have.

https://github.com/Kunzisoft/KeePassDX/wiki/Cloud-Synchronization

[Riajyuu]

@J-Jamet
So do you indicate that KeePass2Android and KeePassDX address different user groups?

[J-Jamet]

@Riajyuu Yes and no, not necessarily. It depends on the needs of each user. I personally created KeePass DX because the technical, functional and code requirements of other applications did not meet my expectations. So I realize this application according to my beliefs in the field of free software and using the technical choices that I learned during my studies.

[Riajyuu]

@J-Jamet OK. One more question:

With KeePass in connected mode, it will be necessary to put the Internet permissions, which will open security breaches.

Why & how? I don't think keepass database has any problem when being transferred even over HTTP.
And I personally transfer that over HTTP if you have to ask, no concern involved.

[J-Jamet]

This is the principle of encapsulation. In software architecture, the software must be created to solve a single main problem. Recovering and sending files over the network has nothing to do with a password manager (In my opinion, let me explain).

To compare with other software. It's like LibreOffice, it does not connect to the internet. To share a text file with a team, we include the file in a shared folder, or we use another FTP service or the synchronization with another application. It's the same with KeePass DX.

If we start to integrate elements related to file sync by third party protocols, we will have to manage all the protocols and sync API in the main app.
This means that we have to be security experts for each of the integrated elements (potentially dangerous because connected to remote servers). It's worse with closed APIs because we do not know the inner code.

Maintainability is also a big problem in this case, for each transfer protocol or integrated API, we must update the entire application and go through the validation workflow.

This is the purpose of a separate file manager application to do these actions (GDrive app, webdav app, or something else) . If your default file manager is not appropriate to your need, simply download one who do what you want. It is also possible to create a file manager connected with plugins for each synchronization protocol. (I have this project in mind but I must already release a final version of KeePass DX.)

So, KeePass DX doesn't directly manage the files but interacts with the content provider https://developer.android.com/guide/topics/providers/content-providers of a file manager application in your device (by default an app with the name "File"). By using a content provider, there is no need for internet access. The app sees the elements that it just needs, no more, no less.

If you see Google Drive during your file selection, it's an integrated file manager app and KeePass DX accesses files by the content provider of this app (with the Storage Access Framework https://developer.android.com/guide/topics/providers/document-provider ) of your file manager.

Each tool does what it needs to do, which is much better for security and interoperability. In the case of Dropbox, the dropbox app seems to not support the Storage Access Framework implementation https://github.com/Kunzisoft/KeePassDX/issues/90 used by the content provider. But it's the fault of dropbox. To alleviate this problem, as I said above, it is possible to create a separate file manager application to handle particular cases.

[cptechnik]

I had tested kpdx with nextcloud sync — not practical...
The function syncing the database by opening and closing... is so necessary... essential...!
I read and understand the problems, ...
But today, the database should be syncable easily...
I mean webdav in this case... (Or ftp or ssh)
If there is a how-to to sync automatically by starting and changing database... I am interested...!

Proprietary file-access maybe like onedrive or Dropbox shouldn't be supported.

[LAGonauta]

If you install OneDrive in your Android you are able to _open_ a KeePass DB in OneDrive, just not create a new one through the app. Not sure why.

[J-Jamet]

The function syncing the database by opening and closing... is so necessary... essential...!
I read and understand the problems, ...
But today, the database should be syncable easily...

For me, the problem is the event that triggers the synchronization of the file of your external manager. The synchronization of your manager should be automatic if the stream of the file used in KeePassDX is written and closed or if another specific event is recovered (a broadcast for example). In this case, what matters is not the transport protocol but only the events which indicate that a file has been modified.

[J-Jamet]

If you install OneDrive in your Android you are able to open a KeePass DB in OneDrive, just not create a new one through the app. Not sure why.

@LAGonauta Simply because this manager ignores requests to open document from Android (Intent ACTION_OPEN_DOCUMENT) because it is not implemented. (See wiki)

[pstorch]

I have successfully opened and stored a keepass database in KeePassDX via OneDrive. First I couldn't save (or save didn't upload). But after I've marked the file in the OneDrive app as "offline" and enabled synchronizing offline files via wifi + mobile then the database was uploaded after I've changed it in KeePassDX.

[pstorch]

After a while KeePassDX said the file does not exist anymore. I assume OneDrive has revoked the access. I had to open it again via FileManager and OneDrive app. But the settings got lost (Biometric unlocking and my keyfile location). Can KeePassDX remember those?

[J-Jamet]

Can KeePassDX remember those?

KeePassDX keeps URI links in memory for biometric recognition and associated settings. If the link is changed by the file manager, KeePassDX cannot link the new URI to an old one since it is simply not the same.

It's like changing the URL of a website. If you specify specific options for this website in your browser, when you change URLs, they are no longer the same options specifically specified in the previous site.

[pstorch]

@J-Jamet never mind. It doesn't happen so often.

[HaujetZhao]

I understand the author's obsession of keeping this excellent app clean. Though, I still got to say I vote for the support for standard open protocal such as ftp, webdav.

I'm a half tech guy, just between the amateur geek and normal dumb users. I can handle the sync problem using Syncthing or other tools. But, a stone is always in my throat about KeepassDX, that is I can't introduce KeepassDX to my friends.

My friends are all common people, not experts with phones or computers, they just the common people, not geeks. Common people all have troubles of forgetting passwords.

I really want to recommand them a excellently beautiful, easy to use, convinient, clean, free and secure password manager, since Keepass2Android's UI and translation is not good, KeepassDX seems to be the only one password manager good enough.

But the lethal problem of introducing KeepassDX to my friends is that: KeepassDX can't backup the database to remote storage. If, on a single chance, the user's phone got damaged, lost, their password will lost forever.

You may say, you got to backup your database, man?

Yeah, I know backup of course, but how about common folks? How much is the percentage that common people know and do the backup? It is a really low percentage! ! !

I don't think KeepassDX is only for geeks, the author also have the desire to provide a clean and pure experience to as many people as possible.

But for now, KeepassDX can't accomplish this goal: Put password in it, set once, secure for after.

The principal of keeping data safe requires at least one copy of the important data must be in a remote storage. If KeepassDX can't do that, the database for KeepassDX users are not secured properly. Even if a part of KeepassDX users backup manually using other apps, still, a big group of KeepassDX user's database are not secured.

I don't count on KeepassDX introducing Dropbox Api or GDrive Api or Onedrive Api, I don't like them either. @J-Jamet

Introducing open protocals (ftp, webdav...) do introduce the netword access permissions, but it won't contaminate the purity of KeepassDX.

On the contrary, if KeepassDX can't make a backup on a remote storage by itself, The Kee in KeepassDX is not qualified since the Keepass means keep password for users and KeepassDX can't keep the database safe following 3-2-1 backup rule.

I have a vision:

One day, KeepassDX can give each database one or more webdav/ftp address, KeepassDX will automaticlly periodly backup these databases. Normal users can just give password to KeepassDX with no more backup steps to to. Even if the phones are lost, they can easily get their latest version of database back.

By that day, I can proudly recommand KeepassDX to my fellows and tell them: you just create a database in KeepassDX and give it your webdav cloud disk backup address, you will have no worry of losing passwords forever!

I wish the vision could come true oneday, or I still got to worry if my backup program is still running everyday.

[pstorch]

@HaujetZhao at least for OneDrive I can say (as reported above) KeePassDX works good together with the OneDrive App (which you should have installed anyway when using this service).

[J-Jamet]

KeePassDX is only a file editor, what you want is a file manager that does what you say.
I understand people prefer all-in-one tools, but here it would just be enough of a file manager app that connects to WebDAV and syncs correctly with KeePassDX (keeping URIs enabled)

At the moment, it's just that none of the file managers you use meet your constraints with Webdav. The solution for this is to create a new WebDAV file manager dedicated app which offers with its content provider the correct synchronization elements to KeePassDX.
From a user point of view, it would be enough to simply download this app in addition to KeePassDX. I just don't have time to create it because I have a lot of other things to deal with.

If the problem is the lack of knowledge of the users, then they must be trained, with a presentation of the operation and animations that explain the concept.

I understand that a lot of people are tempted because all other file managers offer the all built-in method. But I specifically created KeePassDX to separate these elements. Today it just lacks the second good application that could work plugin-based (to add the cloud APIs that everyone wants) and in fact, there are good foundations for creating it (already existing open source apps).

[HaujetZhao]

KeePassDX is only a file editor, what you want is a file manager that does what you say.
I understand people prefer all-in-one tools, but here it would just be enough of a file manager app that connects to WebDAV and syncs correctly with KeePassDX (keeping URIs enabled)

At the moment, it's just that none of the file managers you use meet your constraints with Webdav. The solution for this is to create a new WebDAV file manager dedicated app which offers with its content provider the correct synchronization elements to KeePassDX.
From a user point of view, it would be enough to simply download this app in addition to KeePassDX. I just don't have time to create it because I have a lot of other things to deal with.

If the problem is the lack of knowledge of the users, then they must be trained, with a presentation of the operation and animations that explain the concept.

I understand that a lot of people are tempted because all other file managers offer the all built-in method. But I specifically created KeePassDX to separate these elements. Today it just lacks the second good application that could work plugin-based (to add the cloud APIs that everyone wants) and in fact, there are good foundations for creating it (already existing open source apps).

So I understand it now. KeepassDX is focus on editing keepass database.

I actually got another idea, which won't need the internet permission, while making KeepassDX accord with the 3-2-1 data safety rule.

When users opens KeepassDX, it opens a keepass database from a certain URI, right? The weak point is that, that single file might be damaged, lost, causing data lost. That's why we need a remote storage path. But people also don't like backup manually.

Since KeepassDX can get URI from other content provider, I think it will be no conceptual problem binding multi backup URI address to one existing local keepass database.

So, that's the basic concept: User create or open a local keepass database, which is the main database. Users can also bind single or multi backup address to the main database in KeepassDX. All the backup address are URIs provides by content providers, such as some file manager, or OneDrive app. The read and write process are applied to the main database, but KeepassDX updates all the backup URIs in certain circumstance. Since the remote storage URIs can be provided by the content provider, KeepassDX can periods create remote backup of local database.

The failure of backup process won't cause local database damage, maybe it's just the content provider is not running in the background, using a toast to alert user to check or update the backup URI is enough.

That's it, one database, multi URIs, no Internet permissions. Seems to be a perfect solution.

[pstorch]

@HaujetZhao for Backup there is already a feature request #704

[HaujetZhao]

@HaujetZhao for Backup there is already a feature request #704

Actually they are pretty not the same. The #704 means to create backup version files before saving in prevent of writing error, and it requires KeepassDX to have built-in file manager so that it can create a new backup file.

But the backup I mentioned above is more like sync (single direction sync), it doesn't require KeepassDX to create a new backup file, it just need user to provide one or more (remote) URIs and overwrite them all after saving in prevent of device lost. So this don't need KeepassDX to introduce a built-in file manager.

Without introducing a new component, the development will be way more easier.

[J-Jamet]

Without introducing a new component, the development will be way more easier.

I answered in your new issue but clearly no! The development will not be easier at all. You should not be afraid of new projects (external tool).
Finding hacks to solve a problem instead of creating the correct architecture is clearly not a sustainable solution.

Here it is not just two files, they are pipelines. Concretely, KeePassDX has data streams as input and copying streams is not at all easy depending on the state of these streams.The solution you propose to link two streams coming from different URIs requires to synchronize data (same data in two steams else error), to implement buffers, to verify that the access and the metadata are the same for the two streams, and that the write access is guaranteed. In addition, you have to manage the interface to know which URIs to link, which implies new elements to manage in the internal database of the application, new user screens, etc ...

Or simply make a copy of files with an external tool. (Copying unchanging data with only one input and one output is very easy).

[J-Jamet]

I actually got another idea, which won't need the internet permission, while making KeepassDX accord with the 3-2-1 data safety rule.

In the diagram of the 3-2-1 backup rule, KeePassDX is not a storage actor, it is up to you to implement this storage part according to your needs. The easiest way is to retrieve the file stream closing event when the data has been sent to start the backup routines.

[pstorch]

@HaujetZhao

Actually they are pretty not the same. The #704 means to create backup version files before saving in prevent of writing error, and it requires KeepassDX to have built-in file manager so that it can create a new backup file.

You are right, saving the old version as backup versus saving the same version in a backup location. I mentioned it because the other ticket might be more related than this one. But I now saw you already opened a specific issue for your new idea.