pull down to refresh

Hi all, I wanted to have a little discussion today about the second factor of protection in keepassxc (I'm not sure if this functionality is available in the original version of keepass).
Not everyone knows that you can additionally protect your password database with a key file, which always must be stored separately from the database itself. A key file is any file that can be added to your password database in addition to the master password from the database. It can be a picture, audio or video file, or a key file generated by keepass itself. But the less attention this file attracts, the better.
If you use cloud-based password managers, TOTP codes are likely to be the second security factor. Not too long ago I moved from the cloud-based password manager Bitwarden to keepassxc to regain full control of my passwords. Bitwarden is good, very convenient, but it's still the cloud.
Using a key file, you can safely store the database itself in any cloud storage, contrary to my previous paragraph, without fear of it being hacked. Even if the password database and your master password are stolen, you can't access all passwords without the key file.
This degrades the user experience a bit, but greatly elevates security and your personal peace of mind. It is important to keep the base and the key file separate from each other and make multiple backups.
In my case I have 4 backups of the base in cloud storage and on offline devices (thumb drives, hdd, laptop) and several copies of the key files stored in other cloud storage and other offline devices.
An important note is that the key file should not be modified. For example, if you use some photo as a key file, this photo must not be edited in graphic editors or converted to another format, otherwise when you try to open the database using a modified key file you will fail.
It's interesting to see how much you care about the security of your password database)
Very good! I use keepass too, a bit more simple scenario, but I am very happy with it. I have "my own cloud" with a NAS and synced to another NAS somewhere else. I do not like to use someone else cloud, that means the data is not mine.
I even tried to hack myself to see how protected could be. Is strong AF.
reply
Great, I'm planning to upgrade to my own NAS in the near future too
reply
one step at the time. You are doing great progresses.
reply
I too use a keyfile with KeyPass database, alongwith a strong master password. On my android devices, along with keyfile, master-password; I also enabled fingerprint based security to decrypt the database. I usually set up one-way Syncthing, from my Main PC >>>> to >>>> Android, so that Kee database on my mobile devices is just read-only and give me convenience to login w/o remembering passwords. I just add entries, make edits to database only using my PC, and back it up to my harddisk ASAP.
reply
What application do you use for Android? Keepassdx?
reply
Yes, I find KeePassDX's magic keyboard work pretty well for me
reply
reply
Multi-factor is about something you KNOW and something you HAVE.
A long passphrase eg "The honey badger jumped over the lazy shitcoiner." has sufficient entropy that it doesn't need a file in and of itself.
Backing up the file on a cloud service however negates the HAVE factor. A key file also in the cloud does the same, but knowledge of this keyfile is entropy just like the password.
One could achieve the same ends by obscuring the filetype of the keepass database.
So, there aren't many cases where a long passphrase is made sufficient only by a supplementary file. Odds are it'll just be harder for a deadman to instruct family.
Just use a good long passphrase, because you're only protecting your database with knowledge anyway.
reply
Yes, that's right. You definitely need a complex passphrase with sufficient entropy, but no one is immune to keyloggers, for example. If the passphrase, i.e. the master password, is compromised, the key file will protect against password theft, especially if it is an unremarkable file and only you know that it is the key to the database.
And once again, the key file and the database need to be stored in different places, as do multiple backups, even when considering the cloud. One of the backups of the key file can be stored in the cloud, but the other backups should be stored on offline media. So the ownership factor remains, even if the key file is lost in the cloud.
reply
keyloggers
Very true, and I assume everything is keylogged... and that the NSA has enough Bitcoin so it's better for them not to sweep ours.
But if your keystrokes are exfiltrated, so to would your keyfile under such assumptions. Even if it's stored separately, it's read in the same place.
My point was that it's an extension of the key in all but the rarest circumstances.
Nesting would be an interesting option for the truly paranoid. Ex: A passphrase protected keypass file that, contains yet another keypass file, that is itself keyfile protected for use on a separate airgapped system... that should at least be a moderate inconvenience to a backdoor attacker.
reply