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?
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
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.
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.
For the sake of an example.
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.
A more compact space isn't better, though, unless you're dealing with a character limit. The longer the pass phrase the stronger it is, and you can memorize some seriously long phrases.