Inspired by this post, I decided to see if I could identify any single points of failure in my own setup.
Prerequisites
There are two notable systems that should be mentioned:
The 3-2-1 rule
The 3-2-1 rule can aid in the backup process. It states that there should be at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite, in a remote location (this can include cloud storage). 2 or more different media should be used to eliminate data loss due to similar reasons (for example, optical discs may tolerate being underwater while LTO tapes may not, and SSDs cannot fail due to head crashes or damaged spindle motors since they do not have any moving parts, unlike hard drives). An offsite copy protects against fire, theft of physical media (such as tapes or discs) and natural disasters like floods and earthquakes. Physically protected hard drives are an alternative to an offsite copy, but they have limitations like only being able to resist fire for a limited period of time, so an offsite copy still remains as the ideal choice.
The factors of authentication
The ways in which someone may be authenticated fall into three categories, based on what is known as the factors of authentication: something the user knows, something the user has, and something the user is. Each authentication factor covers a range of elements used to authenticate or verify a person’s identity before being granted access, approving a transaction request, signing a document or other work product, granting authority to others, and establishing a chain of authority.
Security research has determined that for a positive authentication, elements from at least two, and preferably all three, factors should be verified. The three factors (classes) and some of the elements of each factor are:
- Knowledge: Something the user knows (e.g., a password, partial password, passphrase, personal identification number (PIN), challenge–response (the user must answer a question or pattern), security question).
- Ownership: Something the user has (e.g., wrist band, ID card, security token, implanted device, cell phone with a built-in hardware token, software token, or cell phone holding a software token).
- Inherence: Something the user is or does (e.g., fingerprint, retinal pattern, DNA sequence (there are assorted definitions of what is sufficient), signature, face, voice, unique bio-electric signals, or other biometric identifiers).
What KeePassXC offers
KeePassXC is an open-source cross-platform password manager. It mainly stores password databases locally, but you can simply store the file on the cloud for cloud sync. However, this method is botch-y at best, and adds the additional complexity of storing the credentials for the cloud drive.
The database can be protected with any of the following:
Password: This is something the user knows. It can be a password or a passphrase. This can be written down to become something the user has physically, or stored in a file to become something the user has digitally. Storing it in a file is generally not safe due to temporary file leaks.
Key File: This is something the user has. This is stored digitally. This file should either be kept on a separate drive, encrypted with something like LUKS or VeraCrypt, or both. It is possible to convert it to readable text and print it as a physical copy, but reversing the process every time you want to unlock your database would be cumbersome.
Hardware Key: This is something the user has. This is stored physically. You can use hardware security keys such as the YubiKey or OnlyKey for this.
Quick Unlock: This is something the user is. Quick Unlock is only available on Windows and macOS as a form of biometric authentication. It is only available for devices that have a built-in biometric scanner, or by using an attachable biometric scanner. There is most likely a way to achieve this on Linux, but the documentation is scarce.
Any combination of these methods can be used to protect a KeePassXC database. At least one must be used. However, if you use multiple methods, all of them must be used to unlock the database (e.g. if you set up a password and a key file as the methods to unlock the database, you can’t only use the password or only use the key file to unlock it, you must use both.)
The problems
Each method has a single point of failure, and the fact that you can’t set up multiple methods of authentication but choose one to unlock the database means that the more methods you choose to protect your database with, the likelier it will be that one method fails.
Password: This can be forgotten, lost or stolen from a piece of paper (if it’s written down), keylogged or shoulder surfed, leaked through temporary files or stolen (if it’s stored digitally), corrupted or permanently encrypted (if it’s stored digitally), have the drive physically lost or stolen (if it’s stored digitally), unconsciousness (if you only stored it mentally and needed someone else to unlock it for you), or forced our of you with torture.
Key File: This can be leaked through temporary files (if not stored properly), hacked and stolen, corrupted, permanently encrypted (if you are unable to decrypt it), or have the drive physically lost or stolen.
Hardware Key: This can be damaged, stolen, or lost.
Quick Unlock: This can be spoofed (if not set up properly), damaged, general failure to authenticate, damage to you (e.g. facial damage in a fire), or hacked with zero-day vulnerabilities (since Windows and macOS are proprietary).
If any one of these fails, the database is permanently locked.
Some solutions
There are some improvements that you can use to mitigate some of the single points of failure. All methods of authentication can be redone if something happens, but you need to unlock the database to do so (e.g. you can change your database password if it gets leaked, but you need to be able to unlock the database first, so it doesn’t help if you lose your password).
Password: You can store your password using something like a password card. Passphrases are also easier to remember than passwords. Both passwords and passphrases can be safely written down on paper by enciphering them first. However, this introduces new complexities and single points of failure if you are unable to decipher the password.
Key File: The use of the 3-2-1 rule can help make sure the key file never gets lost, but extra care should be taken to make sure the file never gets stolen.
Hardware Key: You can set up multiple hardware security keys in order to make sure if one gets lost you can use the other. One key should be kept with you at all times, and the other should be safely stored somewhere else (such as a safe deposit box).
Quick Unlock: I have never used this feature, but assuming it’s anything like FaceID, you should set up multiple people (such as trusted friends and loved ones) to be able to unlock with biometrics. This ensures that if something happens to you, someone else can unlock it in an emergency or other reasons you may need someone to unlock it for you.
Plugins
While I may be wrong, KeePassXC does not support plugins directly. Ideally you should be able to have plugins for things such as proper cloud sync, TOTP database protection, and changing the all-or-nothing nature of unlocking the database. However, since KeePassXC is open source, someone could make a fork of KeePassXC that supports plugins (please, call it KeePlugXC).
Database syncing
Besides not being able to unlock your database, your database file itself is largely subject to the same single points of failure as a key file. The difference is the database is completely encrypted, and is safe (although not ideal) if it gets leaked. You can store your database in as many places as you’d like, to make sure it never gets corrupted, but the issue is syncing the database as that would be a manual task. The solution presented is the botched cloud storage, but for those who want a local solution, that is not ideal.
Final notes and questions
KeePassXC is very feature rich, so there are other things that can be used to aid the process of preventing database lockouts; but even so, it’s a very difficult task. How is your KeePassXC database set up? Are there any single points of failure? How have you fixed some of the issues listed here? Is there a perfect or near-perfect system for eliminating lockouts?
Unfortunately, as mentioned in the post, there are some ways to lose access to your password that are out of your control. Furthermore, the more places you store your password the less secure it is. It would be a lot easier to be able to authenticate with multiple authentication methods individually, than to rely on having access to all of them at once. That’s the problem I’m trying to address here.
It is still subject to the issues listed in the 3-2-1 rule, however the goal of self hosting itself conflicts with that rule (since the rule dictates the use of off-site cloud storage). I will note, it does somewhat solve the issue of keeping database backups, as any device pulling from the local cloud server effectively becomes a backup of your database.
There is no solution to that problem. If you lose your password it’s gone.
This could be a server that is off-site but still controlled by you. Or just use a cloud hosting provider that you trust, the database is encrypted anyway. Or hell it could even be a hard drive in a box somewhere, assuming you never add anything to your database. Personally my off-site backup is a flash drive that I carry around with me at all times, and manually update whenever I make changes.
That one guy: “I store my backups in a concrete box in the bottom of the ocean. It’s very secure!”
That guy when his system fails: “Hunny, I have to go scuba diving for our passwords.”
(This was meant as a joke)
To be fair, that conjures up a fantastic mental image, LOL. In my head, I see a guy telling his wife that and she’s looking at this dude like “what the actual fuck is wrong with you?”.