Store File in internal storage

[J-Jamet]

Allows to store files in the application's secure space.
Will require import and export methods

Linked to : Kunzisoft/KeePassDX#133

[Jowat97]

Just to make sure: At the moment KeePassDX does not support to store the database in the private storage of the app itself, right? Instead I would need to store it on my public storage, where every other app could have access to it or I could store it within the private storage of a third party app, which will provide it's "private" storage to other apps?

I think it would increase the security and be more convenient, if the app could store the database within it's own private storage. Other KeePass Apps also supports it. It seems like, that this future is requested several times in the past years. It would be really nice to have this function.

[J-Jamet]

Just to make sure: At the moment KeePassDX does not support to store the database in the private storage of the app itself, right?

Yes, I would even say that KeePassDX does not and will not support file storage in any form because it is only an editor.
Please read in detail the conversation of the issue Kunzisoft/KeePassDX#1157.

Instead I would need to store it on my public storage, where every other app could have access to it or I could store it within the private storage of a third party app, which will provide it's "private" storage to other apps?

There is no problem in dedicating an application to perform an action. FileSync will be intended to manage files so it is all for this task but you can use any file manager application you want.

I think it would increase the security

How? Separating the concepts allows you to avoid including bugs in a multipurpose single application that can do everything but with one small flaw can compromise an entire system. Dedicating an application to storage allows the developers who deal with this task to deal with security issues and solve them independently of the file content itself.

and be more convenient

Apart from having two icons for two applications, I don't see what the problem is.

Other KeePass Apps also supports it. It seems like, that this future is requested several times in the past years. It would be really nice to have this function.

I know that's why I have in mind to create this FileSync application that will manage the storage and distribution of files

[Jowat97]

Yeah, I understand your point. And having a separate App to deal with Cloud integration makes a lot of sense. I support your idea, to keep any kind of cloud integration out of your KeePass fork. And yeah, KeePass is somehow an editor for a database, that's true. But using private storage wouldn't increase the complexity of the app etc. since it is natively supported (and recommended) by android. Every app can use it's own private storage to store sensible data in it. No matter, if it is a banking app, a chat app or an "editor". So there is no reason to fear increased complexity, which may lead to (security) bugs.
KeePassDX should have the bare minimal to have a working and safe password manager. And I think having the database stored in a safe place, without the need of third party apps, which may have bugs etc. is part of the security.

See: https://developer.android.com/training/data-storage/app-specific
"These directories include both a dedicated location for storing persistent files, and another location for storing cache data. The system prevents other apps from accessing these locations, and on Android 10 (API level 29) and higher, these locations are encrypted. These characteristics make these locations a good place to store sensitive data that only your app itself can access."

It would be the perfect use case for KeePassDX. It would be possible to store the database within the app and we wold have a closed eco system, without the need of any other third party applications and without the possibility of third party apps to access the database. And since it is natively supported by android, it wouldn't need to code this whole stuff.

After all, it is your app and your decision. I (and probably a lot of other too) like this app but have a strange feeling about the fact, that the database, which literally contains all your security related data, is potentially accessible by every app installed on your device, but could be easily secured.

It would be really nice if you could reconsider your decision and offer the users the possibility to store the database within the app's internal private storage.

Wish you all the best!

[J-Jamet]

But using private storage wouldn't increase the complexity of the app etc. since it is natively supported (and recommended) by android.

That's where you're wrong. It is of course recommended by Android and I recommend it too but under the right circumstances and in the right app.

KeePassDX only manages URIs and does not even know how to manage a file. To store a database file in KeePassDX, we would have to revise the metadata management system to know where these files are stored and how to redistribute them, so we would have to add a new SQL table to manage these metadata in addition to the history table. But as KeePassDX only knows how to manage URIs, it is necessary to create an internal content provider to transform the file streams into generic streams.

And since we shouldn't be jealous and key files are also files, we should do the same for this type of file. It is also necessary to manage imports and exports and all the related UIs.

At the beginning, as KeePassDX is a fork of KeePassDroid, it managed direct file links but it made the code very complex with different stream and rights management everywhere. And with each update, the simplification for maintenance made that only URI are managed in KeePassDX. KeePass2Android kept the way of a all-in-one password manager but I created KeePassDX especially to divide the concepts, otherwise this project wouldn't even exist.

KeePassDX should have the bare minimal to have a working and safe password manager. And I think having the database stored in a safe place, without the need of third party apps, which may have bugs etc. is part of the security.

The funny thing is that that changes described earlier to make KeePassDX compatible with internal file storage would basically be the same code as a dedicated third party application (like Anemo) but would add maintenance complexity for updates.

So for me, the only difference is how much you want to trust a third party application. (If I copy and paste the code of another application to put it in KeePassDX, isn't it worse than using the other application directly? ) Whether the code is directly in the application or not, mainly changes the maintenance and therefore it is easier to fix bugs and increase security on a dedicated app.

See: https://developer.android.com/training/data-storage/app-specific

I know the documentation well, I've been doing Android applications for a long time, here it's a matter of architecture and slicing. I don't question that we can store secure files in the internal memory.

It would be the perfect use case for KeePassDX. It would be possible to store the database within the app and we wold have a closed eco system, without the need of any other third party applications and without the possibility of third party apps to access the database. And since it is natively supported by android, it wouldn't need to code this whole stuff.

There is no security issue in having two trusted applications communicate over a secure data exchange channel, but if you're afraid of that for a trust issue, I understand. In this case, you simply have the wrong application, look at KeePass2Android Offline.

After all, it is your app and your decision. I (and probably a lot of other too) like this app but have a strange feeling about the fact, that the database, which literally contains all your security related data, is potentially accessible by every app installed on your device, but could be easily secured.

Feeling / Potentially words are not sufficient arguments for me. I base myself on the facts, a reflection of the architecture that has been done over years of code refactoring and my experience.

It would be really nice if you could reconsider your decision and offer the users the possibility to store the database within the app's internal private storage.

I can consider it for any file manager app. ;)

Wish you all the best!

I wish you the best too

[kraoli]

I wish I could save the database internally too but I understand the idea of separation and the possible advantage to use it just as a file reader. I don't want to argue about that. :-)

But I wonder how many users are aware that it's not a good practice to save the database in public space and are using an 3rd party file manager?

The mentioned Anemo is the only application I'm aware of. I'm not sure how to find similar applications. Anemo seems like a very small project and is only available on f-droid. I'm still not sure about what to think about it.

Don't you have to enter two passwords when using such storage? One time for Keepass and one time for Anemo?

One comment about your point that copy & pasting the code is no difference compared to using a 3rd party application. It's only true for flaws in the implementation at the time or when you update it automatically as a dependency in your app without checking the changes. Another theoretical threat is the possibility that projects could get hacked and push malicious code in updates. Or are getting inactive and don't work right after an Android update?

[kraoli]

Nothing against the Anemo app. It may be great. But I'm looking forward to your mentioned file provider application. Your very responsive & professional behaviour here generates a lot of credibility. Thanks a lot for your work and great communication.

[J-Jamet]

But I wonder how many users are aware that it's not a good practice to save the database in public space and are using an 3rd party file manager?

We have to identify what you call "public space". Basically I already assume that a phone is personal and that the files belong to the user. If a file is accessible to downloaded applications, the user is responsible for the software he installs so he should trust the applications on his device. It is even asked explicitly if each application has the right to access the device shared files, if the user says yes it means he have full consciousness of that.
If you share your file on a cloud accessible to an external company that can sell it to its partners according to its terms of use, do you consider that your file is in the public domain?

The mentioned Anemo is the only application I'm aware of. I'm not sure how to find similar applications. Anemo seems like a very small project and is only available on f-droid. I'm still not sure about what to think about it.

You can look at the source code, check the permission and simply try out the app. ;)

Don't you have to enter two passwords when using such storage? One time for Keepass and one time for Anemo?

The way Anemo works is to provide a secure space accessible by password, you can open it independently from KeePassDX and less frequently, so yes. But it is up to you to define your file security strategy. I will try to make a more modular file manager application, it just take time.

Another theoretical threat is the possibility that projects could get hacked and push malicious code in updates. Or are getting inactive and don't work right after an Android update?

In this case, it is an advantage. If there is only one entry point and the KeePassDX project makes fraudulent updates, everything is corrupted.
If the entry point is the file manager project, then it can be fixed independently.

But I'm looking forward to your mentioned file provider application

Thank you, it's a lot of work, I'm aware that people are impatient but believe me it will solve many of the recurring problems exposed in the issues.

[J-Jamet]

Also, I would like to remind you that here we are in the FileSync project, so basically, it is still planned to import the concepts of the Anemo application into this application and add features, such as the ability to manage the private storage space with or without a password depending on user needs. It is even its primary goal, and will allow a better management of the updates.
The discussion we have before should be in an issue of KeePassDX and only makes sense if FileSync is not yet deployed.