keepassxreboot
Close button for file attachment
Summary
KeePassXC allows to attach files When opened from within KeePassXC, a copy is created in the temp folder. When modified and saved in the external application, KeePassXC detects the change and saves the changes in the database. The temporary file is only deleted when KeePassXC is closed. A Close button might be added to remove that temporary file even when KeePassXC is still open to prevent sensitive information to stay in the temp folder (e.g. in case of a (computer) crash).
Examples
Context
I included a file with banking codes etc as attachment in KeePassXC and was very surprised to see old copies of the temporary files lingering around in my Temp folder. A Close button could also remove files which were only opened for consulting. When using the button: the user might be warned that any copies still open shall no longer be saved. Or perhaps a warning before removing the file so users make sure the files are no longer open in any external applications.
I didn't dare open this as a bug but it seems to me it's a security issue. It was in my case. I have searched and didn't find a similar report. My apologies if there is.
Interesting idea. I actually wasn't aware that the files don't get cleaned up until keepassxc exits, but it makes sense. It is hard/impossible to determine when the external app is done with the file.
My two cents about the context: many sites offering 2FA would require the user to download a copy of recovery codes, and in that case, it seems quite natural to attach it to KeePassXC. When a user somehow needs the recovery code and opens it externally afterwards, the file in temp folder does contain sensitive information.
I definitely prefer to copy the recovery codes into the notes of the entry. However, the point is made and we can do something about this.
I was wondering also, when the temporary files are deleted from the temp folder (e.g. when closing KeePassXC or the database), are they being securely deleted? If I would have my KeePassXC database on a stick to use it on another computer (work, friend, ...) and I would open the attachment and it isn't securely deleted afterwards then running something simple like Recuva could reveal all contents. Or is this a new issue?
The file is securely erased:
https://github.com/keepassxreboot/keepassxc/blob/a5c1298e3226a59b7430af96757565b0308da312/src/core/EntryAttachments.cpp#L168-L176
Interesting idea. I actually wasn't aware that the files don't get cleaned up until keepassxc exits, but it makes sense. It is hard/impossible to determine when the external app is done with the file.
Double Commander uses a stratagem for the same issue when opening compressed files. The way they've done it is to open a dialog-window which informs the user that while editing the compressed file, the file itself is in uncompressed mode. They then ask the user to confirm when they have done viewing or editing so that the file manager can recompressed the file and wipe the uncompressed copy.
I hope something like this can be implemented. Right now it's a serious security issue, IMHO, as users are not even aware of the issue in the first place and, as @ipatrick456 stressed, there can be situations where the KPXC does not manage to wipe the unencrypted file.
:pray:
It would be interesting to at least have a timer after which temporary files created by opened attachments are cleared.
The clipboard is cleared after 30 sec, attachments could be cleared after 30 minutes.
Off-topic: finally figured out why I always close KeePassXC as soon as I've signed in. I used to do it this way to make sure tmpfile is cleaned and now it becomes a muscle memory.
@Vinfall , which "tmpfile"? This topic is for files stored into the user database and opened manually.
If you simply sign into a website using database-stored credentials, without opening any previously stored files manually, there should be no temporarily file left unencrypted.
Sure, it was obvious that I overact about this. The reply was meant to be a meme, not a proper suggestion regarding the manually opened files in the database. As it confused you, I'll just hide it.
It would be interesting to at least have a timer after which temporary files created by opened attachments are cleared.
The issue I see here is that the user is not aware of this in the first place. Perhaps we could set a locking/unlocking mechanism for the attachments. Instead of the dubious Open button we could have an Unlock button which would make the file accessible in some defined place and Lock to then get rid of it - this way the user is fully aware that he is making it accessible somewhere and then deciding when to get rid of it.
In my opinion, a 30 minute timer seems like a good feature to have as an opt-in, but it definitely should be communicated to the user.. so they do not end up wondering why all of a sudden the file is gone.
@droidmonkey what are your thoughts on this?
With the new attachment preview feature, this is all but moot at this point.
I don't think that is the case, @droidmonkey .
If the file cannot be previewed or else and if the user decides to "Open" it, the issue of which above remains (aka, the file, onced closed remains in the "tmp" folder unencrypted and the user is not alerted.
I still love the "Double Commander" solution the best (see my previous comment) where the user is alerted that is causing a file to be saved on disk unencrypted and asked to confirm when they have finished with it so that it can be automatically deleted.
This would solve some issues with the "timer" proposals (e.g., time not being suitable or KP app being already closed when the time is up).