This post is long and kind of a rant. I don't expect many to read the whole thing, but there's a conclusion at the bottom.
On the surface, recommended security practices are simple:
- Store all your credentials in a password manager
- Use two factor authentication on all accounts
However, it raises a few questions.
- Should you access your 2FA codes on the same device as the password manager?
- Should you store them in the password manager itself?
This is the beginning of where a threat model is needed. If your threat model does not include protections against unwanted access to your device, it is safe for you to store access your 2FA codes on the same device as your password manager, or even in the password manager itself.
So, to keep it simple, say you store your 2FA in your password manager. There's a few more questions:
- Where do you store the master password for the password manager?
- Where do you store 2FA recovery codes?
The master password for the password manager could be written down on a piece of paper and stored in a safe, but that would be inconvenient when you want to access your passwords. So, a better solution is to just remember your password. Passphrases are easier to remember than passwords, so we'll use one of those.
Your 2FA recovery codes are something that are needed if you lose access to your real 2FA codes. Most websites just say "Store this in a secure place". This isn't something you want to store in the same place as those (in this case our password manager), and it's not something you will access often, so it's safe to write it down on a piece of paper and lock it in a safe.
Good so far, you have a fairly simple system to keep your accounts safe from some threats. But, new problems arise:
- What happens if you forget your master passphrase?
- What happens if others need access to your password manager?
The problem with remembering your passphrase is that it's possible to forget it, no matter how many times you repeat it to yourself. Besides naturally forgetting it, things like injuries can arise which can cause you to forget the passphrase. Easy enough to fix, though. We can just keep a copy of the passphrase in the safe, just in case we forget it.
If someone else needs to access certain credentials in your password manager, for example a wife that needs to verify bank information using your account, storing a copy of the password is a good idea here too. Since she is a trusted party, you can give her access to the safe in case of emergencies.
The system we have is good. If the safe is stolen or destroyed, you still have the master passphrase memorized to change the master passphrase and regenerate the 2FA security codes. The thief who stole the safe doesn't have your password manager's data, so the master passphrase is useless. However, our troubles aren't over yet:
- How do you store device credentials?
- How do you keep the password manager backed up?
Your password manager has to have some device in order to access it. Whether it's a phone, computer, tablet, laptop, or website, there needs to be some device used to access it. That device needs to be as secure as your password manager, otherwise accessing the password manager becomes a risk. This means using full disk encryption for the device, and a strong login passphrase. However, that means we have 2 more passwords to take care of that can't be stored in the password manager. We access those often, so we can't write them down and store them in the safe, Remembering two more passphrases complicates things and makes forgetting much more likely. Where do we store those passphrases?
One solution is removing the passwords altogether. Using a hardware security key, you can authenticate your disk encryption and user login using it. If you keep a spare copy of the security key stored in the safe, you make sure you aren't locked out if you lose access to your main security key.
Now to keep the password manager backed up. Using the 3-2-1 Backup Strategy. 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.
So, our first copy will be on our secure device. It's the copy we access the most. The next copy could be an encrypted hard drive. The encryption passphrase could be stored in our safe. The last copy could be a cloud storage service. Easy, right? Well, more problems arise:
- Where do you store the credentials for the cloud storage service?
- Where do you store the LUKS backup file and password?
Storing the credentials for the cloud storage service isn't as simple as putting it in the safe. If we did that, then anyone with the safe could login to the cloud storage service and decrypt the password manager backup using the passphrase also stored in the safe. If we protected the cloud storage service with our security key, a copy of that is still in the safe. Maybe we protect it with a 2FA code, and instead of storing the 2FA codes in the password manager, we store it on another device. That solves the problem for now, but there are still problems, such as storing the credentials for that new device.
When using a security key to unlock a LUKS partition, you are given a backup file to store as a backup for emergencies. Plus, LUKS encrypted partitions still require you to setup a passphrase, so storing that still becomes an issue.
Conclusion
I'm going to stop here, because this post is getting long. I could keep going fixing problems and causing new ones, but the point is this: Security is a mess! I didn't even cover alternative ways to authenticate the password manager such as a key file, biometrics, etc. Trying to find "perfect" security is almost impossible, and that's why a threat model is important. If you set hard limits such as "No storing passwords digitally" or "No remembering any passwords" then you can build a security system that fits that threat model, but there's currently no security system that fits all threat model.
However, that doesn't let companies that just say "Store this in a secure place" off the hook either. It's a hand wavy response to security that just says "We don't know how to secure this part of our system, so it's your problem now". We need to have comprehensive security practices that aren't just "Use a password manager and 2FA", because that causes people to just store their master passphrase on a sticky note or a text file on the desktop.
The state of security is an absolute mess, and I'm sick of it. It seems that, right now, security, privacy, convenience, and safety (e.g. backups, other things that remove single points of failure) are all at odds with each other. This post mainly focused on how security, convenience, and safety are at odds, but I could write a whole post about how security and privacy are at odds.
Anyways, I've just outlined one possible security system you can have. If you have one that you think works well, I'd like to hear about it. I use a different security system than what I outline here, and I see problems with it.
Thanks for reading!
Great write-up, I remember going through this chain of thought myself a few years back and the conclusion I ended at was: you need at minimum one password that you never forget. If you try to create a recovery mechanism, like using a physical safe like OP suggested, then now all your security efforts just shift towards securing that safe instead. Not to mention in some countries the cops can break open your safe but they can't force you to give up your password (aside from using rubber-hose cryptoanalysis).
The good news is, you only need to remember one master password. At least with the system I've been using (feedback welcome). I organize everything into a hierarchy of trust rings. At the root,
ring 0
, is a single device secured with the master password, and it stores the passwords needed for things inring 1
. Then the devices inring 1
store passwords and credentials forring 2
, etc. If I ever forget a password I can always go up a ring to find it. Here's a rough idea of my rings:Ring 0
I use a Pixel phone with GrapheneOS, and a very strong master password. It is permanently in airplane mode so that it is effectively air-gapped. GrapheneOS also supposed a "duress" password, a fake password which can be used to surreptitiously wipe the device if somebody tries to force you to unlock the device. Thus, it is the most secure device I have. It's also a phone so that it's portable enough to carry while traveling. The only thing on it is a KeePass database (which uses the same password as the device itself, for simplicity). This KeePass database contains the disk encryption passwords, login passwords, and BIOS/UEFI passwords for my
ring 1
devicesRing 1
Ring 1
devices are still relatively secure but they are connected to the internet so not as secure asring 0
. I only have 4 things inring 1
: my everyday password manager, my main PC, my phone (also GrapheneOS), and my backup NAS. My everyday password manager contains passwords for things inring 2
.Ring 2
Ring 2
is for things that I consider untrusted and insecure. This includes online accounts, which are ultimately out of my control. Or devices that run untrusted operating systems, like from Microsoft or Apple.Ring 3?
Sometimes on my
ring 2
devices I make throwaway accounts and store the passwords on the device itself, so I guess you could call these throwaway accountsring 3
. But generally everything I own is inring 0
,ring 1
, andring 2
.So there you have it, everything secured with a single password, and I consider it secure enough for most threat models. No need to for physical safes or hiding 2fa keys. It's a little expensive since you have a pixel phone just for storing passwords, but I think it's worth it. It's also a little inconvenient to have to read passwords off the screen and then manually type them in, but I found that I usually remember the passwords for my
ring 1
devices so I rarely need to use myring 0
device.Some tips:
ring 0
, you don't need a separate device if you use Qubes OS. Just use the built-in password vault in Qubes, which I consider as secure as an air-gapped devicering 0
Pixel phone, I couldn't find a way to disable the Android quick settings from the lockscreen, so instead I just removed all airplane/wifi/cellular/bluetooth related toggles from the quick settingsring 0
device contents. I store a backup of my pixel phone's KeePass database on a usb drive. No need for any extra security there, the KeePass database is already encrypted with the master passwordring 0
device, you might want to schedule a monthly routine to unlock it just so you don't forget your master passwordring 0
device like I do, you will want to replace it every few years. Cops have Celebrite machines that can crack any phone except newer Pixel phones.I, too, went through your chain of thought with the "rings of devices". My main problems were:
How do you unlock your database? Is it a passphrase, key file, or security key?
In my chain of thought, this is what I came up with:
My "ring 0" device stores device credentials (BIOS passwords, encryption passphrases, database passphrases, etc. for my laptop, desktop, backup server, phone, and any other devices). Each of those devices has their own KeePassXC database separated from each other. Those databases store the accounts used for that device only (e.g. I only access Lemmy from my desktop, so it gets stored in the desktop database and nowhere else). Those devices and their databases are backed up to the backup server. Ideally this server would be selfhosted, but it's understandable if it isn't.
That system is simple and elegant, but it isn't without issues. Besides the issues listed above, there's no clear way to use 2FA. If the "ring 0" device also has all 2FA codes, that means remembering another passphrase. Where are 2FA recovery codes and other backup methods stored? Likely this would be on the backup server, but offline solutions such as paper and a safe would work too. Where do security keys end up in the mix? What if a KeePassXC database is protected by a key file? Where do you store that?
In the end, it's close to a good solution, but there's unanswered questions. I even started theorizing of a dedicated device manufactured specifically to act as a "ring 0" device, to reduce attack surface. I had to ground myself and make sure I was only thinking about currently available technology.
I'd love your thoughts. It's refreshing to know someone else followed the exact same line of thinking as me.
I'm more than happy to share more about my setup and thought process, so ask away. I'm glad I can finally share and discuss these ideas somewhere. I'll try to separate my responses into sections:
Convenience and Backups
I talk about duress and 2fa codes below, but as for remembering the master passphrase, it's risky but unavoidable. Your entire digital life is made up of information. Devices can be discarded, exchanged, but the information is what matters. There must be a "root" piece of information that unlocks all the rest. If that root key is stored in your brain, nobody else can access it. If the key is anywhere else (like in a physical safe), then anybody with access to that safe can unlock everything else. Maybe you hide the safe somewhere in the ground. Where it is hidden is now your "root key", stored in your brain. Maybe you write the safe's coordinates on a piece of paper. That is now your root key. There is always a root, either you store it in your brain and risk forgetting, or you store it outside and risk it stolen. I don't mind the burden of remembering one piece of information for the rest of my life, if it means the security of everything else.
In my system automatic backups are not needed. This is the advantage of having a small
ring 1
. Thering 0
database only stores the passwords forring 1
, andring 1
rarely changes. For my personal setup, I only need to update thering 0
database when I buy a newring 1
device, which is like once a year at most. Then I just update my backup usb manually.I don't see a way around this, aside from the Qubes solution mentioned in my post.
Handling 2FA
If the root key is air-gapped device or virtual machine (like the Qubes password vault), then it is already 2FA. To access the contents requires both posession of the device and knowledge of the password. I don't use 2FA for my
ring 1
devices either, I don't see much benefit and just added risk. You do have to be wary for a thief that tries to see you typing in your password before stealing your device, but if a thief is that persistent, they could also see you use your 2FA key and steal that as well. I generally use 2FA for important online accounts, where the password can be easily stolen via phishing, database breaches, etc. These 2FA keys are consideredring 1
orring 2
, so their recovery codes can be stored inring 0
orring 1
. Same with keyfiles, if you use those. Remember, the root is simply the master password, everything else can be derived from that.As mentioned in my post, the database has the same password as the phone. I don't see a need for a different one. The phone password is already used for encrypting the entire phone, so you could technically avoid putting a password on the keepass database, but keeping the keepass database encrypted makes backups easier since you can just copy the file to the usb drive. The duress passphrase can be stored in the
ring 0
device as well, as long as you periodically revisit it to refresh your memory.Trust Rings
The system you came up with is good. Whether or not you want to isolate KeePass databases and accounts is up to you, though if you want that level of isolation I would just use Qubes and VMs, much easier than juggling devices.
Though I noticed your system only has two rings. One important thing I should mention is that the ring system is not just for passwords. It is for trust, access, and control in general. Higher rings are more trusted, and can access and control lower rings. For example, my
ring 1
PC has ssh access into myring 2
devices. It would not make sense the other way around. This is why I have multiple rings. Information in lower rings is less trusted. I would not pass an executable from a lower ring to a higher ring unless I have a way to re-validate it, using checksums or PGP keys. Hierarchies of trust are common in security and I find them easy to reason about and very powerful.One of the first diagrams I made when I was trying to sort this out months ago came to this conclusion. I identified 4 media that can be used to store the "root" passphrase:
The last option is most appealing to me, since it doesn't rely on memory and it's more accessible than a USB stick, for example.
This is fair.
Obviously store all your passwords on a sticky note taped to your monitor! /s
It's unfortunate that security costs so much money. Hardware security keys are expensive, and nobody has made that ring 0 device I talked about.
By 2FA recovery codes, I was referring to things like this. I worded my question weird, so I apologize. Account recovery files are common, whether it's a mnemonic seed or those 2FA recovery codes I was referring to. Those shouldn't be stored on the same device as the password manager protecting those same accounts, so there's no clear place to store it. You did answer my question later on, but I wanted to clarify.
I'll comment about this later
I'll give a fun solution for this later, too.
Stopgap
I had a draft if a system, but I need more time to flesh it out. ~~The issue with the database having the same password as the phone is that there's only one form of authentication protecting the
ring 1
credentials in that case (something you know). We have the ability here to protect it with multiple forms, and I will incorporate that into my system once I'm finished.~~ I spoke too soon.ring 0
ordb 0
is something you have, which is the second factor, as you mentioned.As for the fun duress passphrase solution, you could put a sticky note somewhere that is essentially "PHONE PASSWORD: [duress passphrase]" to throw an attacker off and make them accidentally enter it. There's a lot of fun and creativity to be had here. In any case, it means you don't have to remember the duress passphrase, just where it is. "I don't memorize the password to my phone, I store it in that safe over there." etc.
Feel free to reply to this message, and I'll have a working system for you (probably) in the next one.
If someone observed you entering your
ring 0
passphrase and stole your backup ofring 0
orring 0
itself, the database becomes vulnerable. For that reason, it is a good idea to encrypt your database using a different passphrase thanring 0
, and/or mitigate the risk of someone having the ability to see you type yourring 0
passphrase.Storing the
ring 0
passphrase on a hardware security key as I mentioned in the previous reply allows you to automatically type yourring 0
passphrase without the need to remember it or risk being seen typing it in. Another way to mitigate this attack would be enabling biometrics on yourring 0
device. However, that doesn't protect seeing you type the passphrase in a BFU state.This is the method I've come up with:
I have a hardware security key (let's call it
hsk 0
). It is configured to store the passphrase for my airgapped GrapheneOS phone (myring 0
device).ring 0
has biometrics enabled. This meanshsk 0
is only used to unlockring 0
in the BFU state, and can be kept in the safe otherwise. A second factor PIN can be applied toring 0
, and a copy stored in the safe. In general, the second factor PIN will be used often enough to memorize. Myring 0
has a KeePassDX database (db 0
), and Aegis for TOTP (I want to avoid the mixup of saying 2FA when I am referring to TOTP).db 0
is protected using a memorized passphrase, and also has biometrics enabled. I found that storing thedb 0
passphrase using any other medium introduces too many risks and vulnerabilities. Insidedb 0
is the duress passphrase forring 0
, as well as all device credentials forring 1
devices. The Aegis app will store TOTP for all accounts. An unencrypted backup of the phone will be made and stored in the safe.Let's pause here and recap what would need to happen in order to obtain a
ring 1
passphrase:hsk 0
stored in your safe to unlock itIt's important the safe isn't stored in your home, but rather something like a safety deposit box, that way you aren't alone near the safe at any time.
The passphrase for Aegis is stored in
db 0
, and biometrics can be enabled if you want. Eachring 1
device contains an independent KeePassXC database each, that way if a device is remotely compromised while the database is unlocked the damage is minimal. An encrypted backup server is one of thering 1
devices, which keeps all otherring 1
devices automatically backed up. All accounts are protected via 2FA (whether it's another hardware security key (hsk 1
) or TOTP). 2FA recovery codes are stored in a safe separate from ourring 0
backup. That means TOTP follows the 3-2-1 backup method (1 copy onring 0
, 1 backup in a safe offsite, and 2FA recovery codes kept somewhere else. 3 different storage mediums)Now, what an attacker would have to do to break into an account:
ring 0
and compromise Aegis, or find the backup ofring 0
and compromise Aegis, or find the 2FA recovery codeshsk 1
(or a backup of it)Some hardware security keys allow entering a PIN before successful authentication. One of those is good as your "main"
hsk 1
, and the PIN can be stored indb 0
in case you forget (forcing the attacker to also need to compromisering 0
to usehsk 1
).I'm a bit tired while writing this, so please point out any obvious flaws. Here is a summary:
hsk 0
stores the passphrase forring 0
hsk 0
is stored in a safe (safe 0
) when not in use, and a backup can be stored in another safe (safe 1
)ring 0
has biometrics enabled, as well as a second factor PINsafe 0
ring 0
's KeePassDX database (db 0
) stored in memorydb 0
has biometrics enabledring 0
to store all TOTP codesring 0
is stored insafe 0
db 0
stores the credentials for allring 1
devicesring 1
device is used as an encrypted backup server for all otherring 1
devicesring 1
device has their own independent KeePassXC databases (db 1
)hsk 1
) or TOTP.safe 1
hsk 1
is kept insafe 0