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

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.

I remember going through this chain of thought myself a few years back

I, too, went through your chain of thought with the “rings of devices”. My main problems were:

1. Remembering the passphrase for the ring 0 device is risky at best, especially with an added duress passphrase and second factor PIN (if applicable)
2. Keeping the database automatically backed up seemed impossible
3. The added expense and inconvenience of buying and carrying a separate phone was an issue
4. Storing other information such as the duress passphrase or the unlock method for the database had no clear solution

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.

It seems to be a catch 22. People want a simple solution to their security concerns, but without people taking an effort to enhance their security little progress is being made towards creating those simple solutions.

Back when Session was a good messaging app, I was trying to get a friend to move to it. I finally convinced the friend, and their first question was “Where do I make an account?” I explained that there is no account, and the friend asked “Then how am I supposed to use it?” This friend was so used to the abuse of “sign in with your username, password, email, name, date of birth, the name of your first pet, the city you were born, the color of your genitals” that they were confused when that wasn’t there.

Of course creating charts that show your strategy and make your decision predictable is itself just even more privileged information you now need to protect.

Also, any effective threat model also requires consistent reevaluation to assess the effectiveness of your methods and adjust with the evolution of threats.

And so the insanity continues ;)

FWIW I made about 7 charts before giving up and writing this post. I found that charts are far too simple with no easy way to represent the issues.

It seems that these security solutions also, and predicably open up more surface area for problems to arise.

Yes, it breaks the KISS Principal. When trying to increase safety by creating backup solutions, you inevitably add more complexity to the system. That’s why the only simple, elegant solution to security is one that only follows a specific threat model.

I just wanted to let you know that this was a fascinating read.

Thank you!

https://openalternative.co/

From this post

HuggingChat is open source and lets you use DeepSeek. It also doesn’t censor results like the main app (allegedly) does.

Here you go! I had to take some time to consider its specific use case, but I’ve decided it’s unique enough to be its own entry. Thank you!

I will always find the idea of buying ordinary items with Monero to be a little funny. You spend years building up your privacy and go through the effort to have an anonymous Monero wallet and then… buy a towel, or a cup of sugar. I guess because it isn’t fully “mainstream” it’s just a little funny seeing such ordinary things cropping up as an option to spend it on.

Thank you! I have heard of it before, but I haven’t tried it out yet.

Wherever possible!

Hey, if you can manage it, and if that’s what makes you happy, I respect it! I do agree there is more freedom on a desktop, but I’ve found a balance between minimizing my phone usage and still using it for what I need. I really only use it for messaging, news, pictures, and an occasional game.

Yes! Most of them just switched when I asked, very easy. A few were stubborn so I did end up cutting ties.

Here are a few good tips on how you can convince people to switch: https://youtu.be/s9Ux8DFgMSM

So Android it remains for now, alas.

A corporate OS on a mobile device with lots of sensors which follows you around everywhere - this is always going to be a privacy minefield.

Have you taken a look at GrapheneOS? It’s a “de-googled” version of Android, which means it has none of the trackers and even has a network permission toggle for apps.

I’d love to see a website or app that has a full privacy roadmap. Even if there is one, I doubt it would be very good. You need something that constantly reminds you “Hey, you’ve been fighting for privacy for X months, and you’ve achieved so much! Look at how far you’ve come.” It would also need to be tailored to each person, because some people already use Android, others don’t, so the switch to a custom ROM may be harder for some people. It would have to make sure to have easy incremental steps, defined goals, threat modeling, “good” rewards, etc.

Sadly, I’m far from capable of coding that, even if I tried. Best of luck to that one Lemmyer that sees this and says “Hold my beer”

Being able to curate my own news without ads using an RSS reader, never needing to remember or come up with passwords thanks to a password manager, not a single ad thanks to uBlock Origin and Pi-hole, never worrying about songs becoming unavailable or price hikes on streaming services, increased battery life due to no invasive programs running in the background, faster and more reliable devices, and… the list goes on. In a way, you trade convenience in some areas to gain convenience in others.

Thank you!

I’d honestly love to share the whole crazy story of how I got into privacy in the first place, but it would reveal too many personal details about me and other people. It’s not an easy battle, and I’ve certainly made plenty of mistakes along the way, but I wouldn’t change a single thing about how it turned out. It takes a lot of time and effort, so it is unfortunate to see, as you said, many posts of despair.

They would likely put a bounty on it, like they did with Monero.

(I’m only half joking)

Some YouTube clients allow “local extraction” (FreeTube and LibreTube, to name a couple), which sidesteps the need for an instance altogether. However, that then means either 1. You use a VPN to hide your IP from YouTube and risk getting the VPN server IP banned or 2. You don’t use a VPN, expose your IP to YouTube, and have a (small) chance of banning your own IP.

The best alternative would be to remove YouTube altogether and switch to something like PeerTube or Odysee, but you can’t expect all your favorite creators to be there.