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?
Hmm, it seems that the real solution would be to change the database unlock process so that it requires a minimum number of the possible unlock methods, but allows you to set up all of them. So when you create the database, you set up all of the possible credential options, and to unlock you need (for instance) any combination of 2 of them. This way if one credential is lost for any reason it won’t cause a permanent lockout.
Another solution would be a recovery pool. The way this works is that you create a pool of stakeholders who can verify the identity of the admin, and each gets their own set of credentials. If the admin needs to unlock the database but can’t with their own credentials, they can contact the people in the recovery pool and with the credentials of 2 (or whatever minimum number you choose) of them the admin password can be reset. Preferably, the credentials of the recovery stakeholders would not have permission to unlock the database themselves, only to allow the admin password to be reset.
Both of these solve the single point of failure problem without reducing the security of the database, but they would probably require software changes in KeePassXC.
Another solution would be a recovery pool.
That is a really interesting method! Thanks for sharing, I’ve learned something new. A way to solve the stakeholders unlocking it would be to also require the admin’s own credentials plus 2 (or however many) stakeholder credentials to unlock it. However, that could cause stakeholders to target the admin.
Yeah, you could also use this method to protect high-value assets all the time, not just for recovery. Require a minimum number of personnel to login by default. It’s always a question of balancing security needs vs. ease of use.
So my phone is my primary computing device and it is Android running lineage OS with no Google Play services. So my primary use of keepass is through an app called keepassDX. My method is that I have a passphrase with some special symbols that unlocks my database and it is decently long. I store my main copy of my database on my phone and update it when I need to add an account, etc. Generally every quarter of the year, I will back up the key pass database onto two separate flash drives And once a year, I send my key pass database to a friend of mine who holds it for me so that if my phone and flash drives were ever lost in a fire, I could still get it back from them, but they obviously don’t know the password. This means if my phone ever broke and I was not able to retrieve the database, the most data I would lose would be three months. Worth. And if my phone and flash drives were ever in a fire, the most data I would lose would be a year’s worth. There are probably slightly better methods than what I have outlined here, but I do not want to use any kind of cloud provider at all.
My method is that I have a passphrase with some special symbols that unlocks my database and it is decently long.
Where is your password stored? If it’s only by memory, what happens if you forgot it or needed someone else to unlock it in an emergency?
Yeah, its memory only. I have been toying with proper ways of securing it and very seriously thought about splitting it in three parts and keeping one and giving the other two to different people so that they would have to collude to break it.
Like “cheeseburger” would be
Person 1: c–e–b–g–
Person 2 : -h–s–u–e-
Person 3: --e–e–r–r
As long as the other people do not know each other, and I leave instructions say in a lock box that one other person has the key to and leave the phone number for the other person, then they could talk if I am incapacitated and crack the password.
You could technically achieve this by giving one person the password, another person the key file, and the third person the security key.
You know that is quite a good point. You would have all three and they would all three also be held by somebody else. But different people.
Edit: I just did think of one potential issue with this, and that’s the fact that in your possession would be at least two of the three items, the physical key that you need, and the key file that you need. So someone who got to you would have at least two of the three by default.
So someone who got to you would have at least two of the three by default.
Both are useless without the third, and can be easily regenerated. Also, you can be tortured for your passwords.
True, I wasn’t necessarily thinking torture. I was thinking more along incapacitation lines. But if somebody is torturing you, there’s a good chance you’re going to give up the database. No matter what.
Also, someone can hijack your contacts and bribe/torture all 3 people into giving them your credentials.
You’ve already answered your own questions in the “Some Solutions” section. If you completely lose your password to your vault there is nothing you can do, simple as that. Don’t lose it.
Cloud-based sync is incredibly easy with self-hosted cloud, as pointed out by the KeePassXC FAQ. Self-hosted cloud is effectively a local solution.
If you completely lose your password to your vault there is nothing you can do, simple as that. Don’t lose it.
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.
Cloud-based sync is incredibly easy with self-hosted cloud, as pointed out by the KeePassXC FAQ. Self-hosted cloud is effectively a local solution.
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.
That’s the problem I’m trying to address here.
There is no solution to that problem. If you lose your password it’s gone.
off-site cloud storage
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.
Or hell it could even be a hard drive in a box somewhere
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?”.
I think a pass phrase is more secure than a password because you can memorize truly huge strings without worrying about ever losing it.
Most passwords can be converted to passphrases to help you remember them. A password “8pmfvt3bww7t” could be remembered as “8 pandas might find vases that 3 bears will wash 7 times.” Obviously not all passwords will work for this, but it’s a good way to remember random strings. Passphrases are long in characters but have an entropy dependent on how long your wordlist is. For example, 3 words might be 20 characters, but it’s easy to guess 3 words since you’re not going character by character.
A password “8pmfvt3bww7t” could be remembered as “8 pandas might find vases that 3 bears will wash 7 times.
You’re going to have to explain to me why the first password is more secure than the second pass phrase. The second has more characters and that’s the only thing someone trying to guess is going to possibly know. There’s nothing else to go off of, they don’t even know they’re trying to guess words in the first place. The longer string is always more secure afaik
they don’t even know they’re trying to guess words in the first place.
That is true, but the math is still the same regardless.
Suppose you had a word list of 1,000 five letter words. Each of your passphrases is 5 words long. That means you have 1,000^5 possible combinations of passwords, which is an entropy of ~49.8 bits. Even though each passphrase is going to be 29 characters long (5 five letter words plus 4 spaces in between), the password wasn’t generated character by character.
By contrast, suppose you used all 95 characters on the (US) keyboard, an 8 character password has 95^8 combinations, which is an entropy of ~52.6 bits. Even though the passphrase has 21 more characters than the password, the password still has more entropy.
Big grain of salt here: You can get a huge word list and remember much longer passphrases easily, but the point is to show that the number of characters doesn’t dictate the security of a password. If someone were to brute force a passphrase character-by-character, it would hold up very well, but a) Not many people use passphrases and b) It’s far more common to use password dictionaries than to brute force.
Hope this helps! Here’s the Wikipedia page for password entropy
P.S. If someone found your word list, they could probabilistically brute force your passwords. For example, if 75% of your five letter words started with the letter S, they could deduce that most of the words likely start with S, and they’ve already eliminated a few characters to brute force.
Suppose you had a word list of 1,000 five letter words. Each of your passphrases is 5 words long. That means you have 1,000^5 possible combinations of passwords, which is an entropy of ~49.8 bits. Even though each passphrase is going to be 29 characters long (5 five letter words plus 4 spaces in between), the password wasn’t generated character by character.
That’s a lot of supposition.
The reality is the password guesser has a string of 29 characters. All they know is ***************************** - they do not know they are guessing individual words separated by spaces, and even if they know these are words they do not know what word list is being used so they have every word that has ever existed as part of a possible list, they do not know the length of any of the individual words being used, and to top it all off they do not even know if the words have conventional spellings or are English words or anything!
So actually, you have a string of 29 characters, and they might as well be random characters as far as a password guesser can guess.
Although I will grant that pass phrases are unlikely to use unconventional characters !$#@;<> etc so you have a point there.
That’s a lot of supposition.
For the sake of an example.
The reality is the password guesser has a string of 29 characters.
Actually, not even that. It would be hashed as a fixed length (256 bits usually).
Again, most of what I was saying was just for the sake of an example to show that under the right circumstances the length of a password doesn’t dictate its security. Even if it’s an extreme, security is only as strong as its weakest link. I’m not denying that it can be unrealistic, and I’m not saying it’s insecure (hence the “grain of salt” section that addressed all of your points), I’m just showing how it could be possible.
What you failed to demonstrate is that passwords are better than pass phrases, and that’s my point. In order to crack my pass phrase you have to have tons of additional information like the fact that I use a pass phrase, what the rules are for the words in my pass phrase, the list of words I draw from for my pass phrase, etc. Your suppositions are required to beat it.
As long as you generate your passphrases properly (i.e. making sure they still have high entropy and don’t fall into the same pitfalls I listed, in case someone still decides to brute force your password as a passphrase), you can have a very secure passphrase. However, as far as sheer entropy goes, passwords have more entropy in a more compact space and are better in that respect.
P.S. Some applications have a character limit, meaning you’ll get more entropy out of a password than a passphrase. You might accidentally get weak entropy in a passphrase because of the character limit.
i never thought about this before. honestly i feel as though this would be better than diceware or passphrases:
- you dont have to type in something 10x as long, so you can get a lot more entropy in a smaller space
- the mnemonic can be anything you want it to be as long as the words start in the respective letters, so you can make it much more memorable, thereby making it a lot easier to remember very long passwords.
you dont have to type in something 10x as long, so you can get a lot more entropy in a smaller space
This is especially useful when you require a lot of entropy, having an essay as your passphrase isn’t very fun!
the mnemonic can be anything you want it to be as long as the words start in the respective letters
You can even make up your own rules, not just starting with the respective characters.
