Hide and obfuscate the stored file

[kostas-kelgeorgiadis]

I was just testing the addon and I immediately got something that was bugging me:
There is no way to hide the presence of the database file in your cloud storage provider (which might be a good idea, since you or the cloud storage provider might be hacked).
My suggestions would be these:

1. Provide the ability for users to specify the location/path where the backup is saved on the cloud, so that we can avoid using a path containing the term 'KeeAnywhere', which reveals the contents of the folder.
2. Provide the ability to save the file without the .kdbx extension. I have tried choosing the All Files (*.*) filter while saving, but it still adds the extension to the saved file, which is a deviation from how Windows Explorer save-dialogs work.
3. My guess is that kdbx files have a file-signature, so it might be a good idea to ZIP them in a password protected ZIP file before upload. Or encrypt them. That way, having access to the files does not reveal the presence of the password database.

[Jackabomb]

1. You can already do this. I just tried it (with Google Drive).
2. You can already do this. I just tried saving as a .txt (with Google Drive). No extra extension was appended for me.
3. This would be better off as a separate plugin. Personally, I feel it's just "security by obscurity".

Maybe some of this is cloud-provider specific? I can already do 2 of your 3 options with Google Drive.

Caveat on the file extensions: I can save it with any extension I like, but I cannot save it with no extension at all. If I try, then, as you say, the kbdx extension gets automatically appended. I tried a local file with no extension. Same thing, so this must be intrinsic to KeePass itself.

[kostas-kelgeorgiadis]

@Jackabomb
Interesting.
I have only tried with DropBox, assuming it would be the same for all.
It created a folder structure like Apps/KeeAnywhere/sth.kdbx for me.

I can save it with any extension I like, but I cannot save it with no extension at all.

That might be it!
I have only tried without an extension.
Although, it would be good to be able to save without one, because most extensions go hand in hand with a specific file header/signature.

In theory, the file should be secure as it is, with the normal extension and with the file header.
The point is to make its existence unnoticeable, not to make it more secure.
Also, the file might be considered secured today, with the current encryption, but be considered unsecured a few years later.
The point is to prevent people detecting its existence and getting it in the first place.
If they get it and they know what it is, then you have no control over the situation any more.
They might break it 5 or 10 years later.

[Daniel Bölts]

These Questions come up from time to time and my opinion to this is still: * I will not implement any obscuring logic: it does not improve any security * I completely comply to KeePass's standard features if possible and do not add any function that exists in KeePass itself * If you put your Database in a cloud system you should always treat it, as it would be completely public - if you fear it could be hacked in 5 or 10 years, then *you* should have a strategy for that (e.g. changing passwords from time to time), so the data is useless in the future * If you do not trust KeeAnywheres cryptographic algorithms, then you maybe should not push your database to a cloud system * Keep an eye on machines stealing databases, as well social engineering/hacking * nothing is 100% secure :-) Am Mi., 7. Sept. 2022 um 09:48 Uhr schrieb kostas-kelgeorgiadis < ***@***.***>:

…

@Jackabomb <https://github.com/Jackabomb> Interesting. I have only tried with DropBox, assuming it would be the same for all. I can save it with any extension I like, but I cannot save it with no extension at all. That might be it! I have only tried without an extension. Although, it would be good to be able to save without one, because most extensions go hand in hand with a specific file header/signature. In theory, the file should be secure as it is, with the normal extension and with the file header. The point is to make its existence unnoticeable, not to make it more secure. Also, the file might be considered secured today, with the current encryption, but be considered unsecured a few years later. The point is to prevent people detecting its existence and getting it in the first place. If they get it and they know what it is, then you have no control over the situation any more. They might break it 5 or 10 years later. — Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACWW2XCPP4AWSI746KLYZDV5BCFFANCNFSM6AAAAAAQASAIQE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kostas-kelgeorgiadis]

Okay.
You can close this issue if you want then.
I just wanted to point out that it struck me in a negative way, the whole "advertisement" of the file as a passwords DB file once I entered my DropBox account.

Regarding your points, I have some counter-arguments, but I don't know if they have any value.
Like the fact that people could store things that cannot change in their pwd manager (e.g. ID numbers, telephone numbers, and what not...) or the number of credentials they store in there makes it practically impossible to change all passwords from time to time.
But I see your point, and we probably don't need to discuss it further here. ;)