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!

  • The 8232 Project@lemmy.mlOP
    1·
    2 days ago

    There must be a “root” piece of information that unlocks all the rest.

    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:

    1. Memory
    2. Pencil and paper (or some other physical engraving)
    3. An unencrypted digital storage device
    4. A hardware security slot (you can configure a YubiKey to automatically type a specific password when tapped)

    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.

    For my personal setup, I only need to update the ring 0 database when I buy a new ring 1 device, which is like once a year at most.

    This is fair.

    I don’t see a way around this, aside from the Qubes solution mentioned in my post.

    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.

    If the root key is air-gapped device or virtual machine (like the Qubes password vault), then it is already 2FA.

    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.

    As mentioned in my post, the database has the same password as the phone.

    I’ll comment about this later

    The duress passphrase can be stored in the ring 0 device as well, as long as you periodically revisit it to refresh your memory.

    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 or db 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.

    • The 8232 Project@lemmy.mlOP
      1·
      2 days ago

      If someone observed you entering your ring 0 passphrase and stole your backup of ring 0 or ring 0 itself, the database becomes vulnerable. For that reason, it is a good idea to encrypt your database using a different passphrase than ring 0, and/or mitigate the risk of someone having the ability to see you type your ring 0 passphrase.

      Storing the ring 0 passphrase on a hardware security key as I mentioned in the previous reply allows you to automatically type your ring 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 your ring 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 (my ring 0 device). ring 0 has biometrics enabled. This means hsk 0 is only used to unlock ring 0 in the BFU state, and can be kept in the safe otherwise. A second factor PIN can be applied to ring 0, and a copy stored in the safe. In general, the second factor PIN will be used often enough to memorize. My ring 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 the db 0 passphrase using any other medium introduces too many risks and vulnerabilities. Inside db 0 is the duress passphrase for ring 0, as well as all device credentials for ring 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:

      1. An attacker would need either the phone or a backup of it
      2. If the attacker has the phone in a BFU state, the attacker would need hsk 0 stored in your safe to unlock it
      3. If the attacker has the phone in an AFU state, the attacker would need your fingerprint as well as the second factor PIN you have memorized or a copy of it in your safe
      4. Once the attacker unlocks the phone, or if the attacker only has a backup of the phone, the attacker would need the passphrase only you know in order to unlock the database.

      It’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. Each ring 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 the ring 1 devices, which keeps all other ring 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 our ring 0 backup. That means TOTP follows the 3-2-1 backup method (1 copy on ring 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:

      1. Compromise the device hosting the KeePassXC database storing the account
      2. Compromise the KeePassXC database
      3. If the account is protected by TOTP: either compromise ring 0 and compromise Aegis, or find the backup of ring 0 and compromise Aegis, or find the 2FA recovery codes
      4. If the account is protected by a hardware security key: Find hsk 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 in db 0 in case you forget (forcing the attacker to also need to compromise ring 0 to use hsk 1).

      I’m a bit tired while writing this, so please point out any obvious flaws. Here is a summary:

      1. A hardware security key hsk 0 stores the passphrase for ring 0
      2. hsk 0 is stored in a safe (safe 0) when not in use, and a backup can be stored in another safe (safe 1)
      3. ring 0 has biometrics enabled, as well as a second factor PIN
      4. The second factor PIN is both memorized and a copy stored in safe 0
      5. You have the passphrase for ring 0’s KeePassDX database (db 0) stored in memory
      6. db 0 has biometrics enabled
      7. Aegis is installed on ring 0 to store all TOTP codes
      8. A backup of ring 0 is stored in safe 0
      9. db 0 stores the credentials for all ring 1 devices
      10. One ring 1 device is used as an encrypted backup server for all other ring 1 devices
      11. Each ring 1 device has their own independent KeePassXC databases (db 1)
      12. All accounts are either protected with another hardware security key (hsk 1) or TOTP.
      13. 2FA recovery codes are stored in safe 1
      14. A copy of hsk 1 is kept in safe 0
      • rsorssae@thelemmy.clubEnglish
        1·
        21 hours ago

        You’re system sounds well thought out and more than secure enough for most people’s needs, so if that is what works for you I would go for it. I also like the fun idea for the duress passphrase, I just hope a friend doesn’t get tempted to try and unlock your phone and accidentally wipe everything! Overall, the only comments I would make are:

        • be wary of using biometrics for ring 0, in countries like the US the cops can force you to use your biometrics, by law. GrapheneOS does have ways to quickly disable biometric unlock in emergencies, or automatically disable it after a set period of time
        • you are using both a security key and a passphrase for securing the ring 0 database. Perhaps commit to one of them, to reduce complexity. The more complicated the system, the more places there can be vulnerabilities
        • getting access into the ring 0 device is effectively compromising the database, even if you have a password on the database. There are numerous things that an attacker can do once in control of the device, like enabling internet, flash a custom rom and copy all the files over to make it look identical, installing a keylogger, changing the UI to hide any modifications, etc. This is also why I try to use my ring 0 device as little as possible, every time I enter the password is another chance for the password to be stolen
        • putting your Aegis TOTP app on ring 0 means you have to constantly use your ring 0 device. I prefer to use my ring 0 device as little as possible, both for security and convenience. My TOTP app is on a ring 1 device instead, and is only used to secure online accounts (which I consider ring 2). If you want to use 2FA for ring 1 then I suppose you are forced to put your TOTP app on ring 0, though I find the inconvenience not worth it.