I got the idea from someone saying the best way is to hide the needle in a stack of needles, not in a haystack.

I am considering writing a little app to accompany my Keepass installation. The app would create X (1024?) .kdbx files with random encrypted data of various sizes. They would have random 3 character names. I can then delete any of those files and save my "live" database in its stead. After I am done with my Keepass session, the app would then need to 'reset' all time related meta-data (date and time last edited, for example) of all 1024? to avoid my "live' .kdbx file to stand out of the stack of needles.

The idea is to discourage a would-be password brute force attack.

Other than having to remember a 3 letter word, what down sides does this have?

  • I'm not familiar with the Keepass file format, but I suspect that certain parts of the database file don't change between saves. An attacker could just grab a few copies of your needle-stack and look for files that have similarities, since the other files are just random data. Aug 4, 2015 at 16:57
  • That I would definitely need to have a look at. I was thinking about that as well. The idea is to have x amount of .kdbx clones in there ... if that at all is possible. Aug 4, 2015 at 17:04
  • Where would these files be stored? You assume that someone which would have the possibility to access these files (+ the required knowledge to break their encryption) will not have the possibility to check which one you are actually opening (ie. listing currently opened files on your system, should I also mention dropping a keylogger in your session)? Aug 5, 2015 at 13:29
  • The files would be stored together with the the database in an obvious location, most likely the default path. Aug 12, 2015 at 6:43

1 Answer 1


What you are trying to do is to add an additional "security by obscurity" layer on top of the normal authentication layer which is the "security by design" layer. Yes, it will increase the amount of work an attacker must perform.

There is a simpler solution to achieve the effect which you desire. KeePass allows you to use a key file in addition to a password. The key file can be any file on your system. There are literally thousands of files already on your system. The attacker needs to get both the password and the file correct. Since KeePass does not write to the file, you don't have to worry about any of that timestamp problem.

By choosing to write an app to perform the function, you need to make sure that there are no bugs in the app, you must also remember to run the app to reset the metadata every single time. These are additional problems which can be avoided. Bugs can have catastrophic consequences. (E.g. Overwriting your actual password database)

Make sure to choose a file that does not get modified through system updates. I am currently using an mp3 file from my vast 10GB music collection. Good luck finding the right one.

  • The idea is to straight up discourage a human from brute forcing. I want him to see that he needs to find the right database to attack. If he attacks one of the fakes, he will be running in a circle, never knowing when (or if ever) he will crack the encryption. Aug 4, 2015 at 17:30
  • But I was not aware of that keyfile feature, which is awesome. Aug 4, 2015 at 17:30
  • 1
    Same thing here, if he doesn't know that you use a keyfile in addition to a password, he can try all possible password combinations and never be able to crack it Aug 4, 2015 at 17:31
  • 5
    So the next question to ask yourself is: What is the possibility a human would want to brute force my KeePass password, but not badly enough to try if he/she found 1000 db files? The answer will be specific to you, but I know for me, the risk wouldn't be great enough to justify the effort.
    – Xander
    Aug 4, 2015 at 22:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .