Quick question. I'm considering creating a plugin that would help with plausible deniability. One important aspect is obfuscation at the file system level. So,
Do keepass plugins have access to the local file system?
Can plugins create or modify thier own db files?
Can plugins change the datetime stamps of files?
I'm hoping someone might be able to provide a quick answer and save me trawling through the plugin api documentation.
Many thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no security by obscurity and plausible deniability belongs to this category of features.
In a real case you will pe pressed to give your secrects and that will not stopped by plausible deniability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course there is some security to be had if an item remains undetected. You won't ever be pressed to give up a secret if the asker doesn't know you have a secret in the first place. Plus, KeePass doesn't just hide keys, it also hides the fact that a lock exists. Consider, you have a database that you use, and then backups spanning the last few years. In amongst your old backups, you hide a second database. You can plausibly argue that you don't remember the password you used for a database two years' ago, but not if your system shows you modified the file yesterday.
Edit: please don't comment unless you're addressing the question.
Last edit: Davii 2017-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dominik (the KeePass author) seems to go out of his way to make "plausible deniability" and other obfuscation techniques difficult to implement with KeePass. He argues that users would abandon other, truly effective security practices in favor of these if given the chance, therefore he refuses to give users the opportunity to shoot themselves in the foot and then blame KeePass. My argument (that people who do understand and want to use these techniques as an adjunct to other safeguards and not as a substitute should not be prohibited from doing so for the sake of uneducated users, since uneducated users are more than capable of shooting themselves in the foot with or without these restrictions) hasn't had any effect on his opinion in all the years that I've been making it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't mean to hijack your thread; I just wanted to explain that Dominik may have deliberately avoided providing hooks for what you want to do for similar reasons, and so may be similarly reluctant to add them. I'll shut up now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you run an external command (via a trigger) to change the dates on the database you just saved?
Saves having a PD plug-in, which kind of gives the game away.
cheers, Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@T. Bug Reporter - Sorry, I wasn't complaining about you. Your explanation was helpful information, and told me that I might encounter prejudiced feelings. I was hoping my comment might stop the thread devolving into a 'plausible deniability' war, and encourage people to look past those feelings for a moment.
@Paul - Thanks, I hadn't investigated the trigger system. I presume the list of actions it has, regarding executing commands, openning databases, etc., will be available in the plugin api, so at least there's that. However, I fear it also suggests that is likely to be all there is. You're right that a plugin might well give the game away. Unfortunately, by the same token, so would an entry in the trigger system. If I get as far as writting a plugin, one of the first steps will be to try to come up with a way to allow it to hide itself, as well as hiding what it's done.
Instead of a plugin, it is of course possible to have a script that changes datestamps, and keep that script as an attachment in the database. The steps to close the db would then be: open entry with script, click advanced tab, select script, save script to desktop, close db, run script, delete script. There are a number of potential pitfalls here, and it should be noted that what I'm considering doing is creating a plugin that would provide this feature, whilst avoiding sore feet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Everything you need to implement such features via a plugin should already be there.
For example, if you want to reset the file times of a database after it has been saved, I'd suggest that your plugin subscribes to the MainForm.FileSaved event and reset the file times when the event is raised (the database file path can be obtained from the event arguments object e by e.Database.IOConnectionInfo.Path).
Best regards,
Dominik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quick question. I'm considering creating a plugin that would help with plausible deniability. One important aspect is obfuscation at the file system level. So,
I'm hoping someone might be able to provide a quick answer and save me trawling through the plugin api documentation.
Many thanks in advance!
There is no security by obscurity and plausible deniability belongs to this category of features.
In a real case you will pe pressed to give your secrects and that will not stopped by plausible deniability.
Of course there is some security to be had if an item remains undetected. You won't ever be pressed to give up a secret if the asker doesn't know you have a secret in the first place. Plus, KeePass doesn't just hide keys, it also hides the fact that a lock exists. Consider, you have a database that you use, and then backups spanning the last few years. In amongst your old backups, you hide a second database. You can plausibly argue that you don't remember the password you used for a database two years' ago, but not if your system shows you modified the file yesterday.
Edit: please don't comment unless you're addressing the question.
Last edit: Davii 2017-11-24
Dominik (the KeePass author) seems to go out of his way to make "plausible deniability" and other obfuscation techniques difficult to implement with KeePass. He argues that users would abandon other, truly effective security practices in favor of these if given the chance, therefore he refuses to give users the opportunity to shoot themselves in the foot and then blame KeePass. My argument (that people who do understand and want to use these techniques as an adjunct to other safeguards and not as a substitute should not be prohibited from doing so for the sake of uneducated users, since uneducated users are more than capable of shooting themselves in the foot with or without these restrictions) hasn't had any effect on his opinion in all the years that I've been making it.
It appears that I've stumbled upon a nerve. Please can we pretend that I never mentioned the reasons for my question? Pretty please :-)
I didn't mean to hijack your thread; I just wanted to explain that Dominik may have deliberately avoided providing hooks for what you want to do for similar reasons, and so may be similarly reluctant to add them. I'll shut up now.
Can you run an external command (via a trigger) to change the dates on the database you just saved?
Saves having a PD plug-in, which kind of gives the game away.
cheers, Paul
@T. Bug Reporter - Sorry, I wasn't complaining about you. Your explanation was helpful information, and told me that I might encounter prejudiced feelings. I was hoping my comment might stop the thread devolving into a 'plausible deniability' war, and encourage people to look past those feelings for a moment.
@Paul - Thanks, I hadn't investigated the trigger system. I presume the list of actions it has, regarding executing commands, openning databases, etc., will be available in the plugin api, so at least there's that. However, I fear it also suggests that is likely to be all there is. You're right that a plugin might well give the game away. Unfortunately, by the same token, so would an entry in the trigger system. If I get as far as writting a plugin, one of the first steps will be to try to come up with a way to allow it to hide itself, as well as hiding what it's done.
Instead of a plugin, it is of course possible to have a script that changes datestamps, and keep that script as an attachment in the database. The steps to close the db would then be: open entry with script, click advanced tab, select script, save script to desktop, close db, run script, delete script. There are a number of potential pitfalls here, and it should be noted that what I'm considering doing is creating a plugin that would provide this feature, whilst avoiding sore feet.
I hope you are going to clear up Windows file access history as well.
cheers, Paul
Everything you need to implement such features via a plugin should already be there.
For example, if you want to reset the file times of a database after it has been saved, I'd suggest that your plugin subscribes to the
MainForm.FileSavedevent and reset the file times when the event is raised (the database file path can be obtained from the event arguments objectebye.Database.IOConnectionInfo.Path).Best regards,
Dominik