Been thinking about this for a while and wanted to hear how this community sees it.
I use KeePassXC - encrypted database, strong master password, the works. But the more I think about the actual threat model, the less confident I feel. The database gets decrypted inside the OS, in RAM, right next to the browser and every other running process. If a machine gets hit with an infostealer, the attacker doesn’t need to crack anything - they get the master password and the decrypted database in one pass. And there’s no way to know it happened until your accounts start getting used.
So software password managers solve one problem really well - using unique, strong passwords per site, which protects against credential stuffing when a database leaks somewhere. But they do nothing against a threat that’s arguably far more common in practice - malware on an already-unlocked system, which steals the master password and the entire database in one go.
Genuinely curious what people here think:
Do you consider this a real gap, or am I overweighting infostealers as a threat?
Has anyone moved to keeping credentials off the PC entirely (hardware token, offline device, paper, etc.)?
If you were to design a “physical” password manager from scratch, what would it need to actually earn your trust?
Tools only serve specific purposes, overall security is always multifaceted. Knowing how to protect yourself from malware is as essential as choosing a good password manager.
This is where security keys (especially YubiKeys) are very useful. An infostealer on your computer wouldn’t be able to access your passkey private keys or TOTP secrets, at worst they should only gain temporary access to your accounts. Anyone who can’t afford a security key could store secrets on their Android/iPhone instead of their PC as they’re usually much more secure against malware.
Agreed, you’re right about security keys - they genuinely close that specific vector: passkey and TOTP secrets are physically isolated on the key, an infostealer can’t reach them.
But here’s the nuance: that works great for authenticating into individual services. The question was about something different - the primary secret, the one key that unlocks everything else, which can’t really be moved to a YubiKey in the first place because there’s no standard for it. LUKS - just a password. PC root - just a password. The KeePassXC database itself - also just a password, because there’s nowhere to fit OTP. A crypto wallet seed phrase - no 2FA involved by design at all.
And here’s the funny part: someone can easily have TOTP set up on a game store account, while having zero protection on their crypto seed phrase, which usually just sits as plain text somewhere on disk or in the same password database. We end up protecting the stuff that’s relatively low-stakes anyway, while leaving the actually valuable thing completely exposed.
I’d also push back on phones being inherently safer. To me it all looks equally leaky, just a different attack surface. Moving secrets from a PC to a phone isn’t solving the problem, it’s just relocating it to wait there instead.
And there’s the AI angle too - generative models are already capable of writing functional malicious code, and polymorphic, adaptive malware we haven’t even seen yet seems to be right around the corner. So betting on “this device is safer than that one” feels like a pretty shaky long-term strategy.
Password managers are not a solution against malware, you are comparing oranges and apples.
If your system is compromised there is no tool that is safe.
If your threat model is malware you should consider other measures.
Disagree. “If the system is compromised, nothing is safe” only holds when the secret lives on that system - like with a software manager. If the secret never lives on the PC at all, and only arrives as a finished password at the moment of entry, malware can catch that one password, not the whole database.
There’s been advice to lock the password manager app between uses. For KeepassXC, that’d be a ctrl-l to do that for the desktop application (keys may vary between OS).
To me, this is probably good, but adds a lot of friction if one has a difficult password to type or a really really long password (20+ chars or so), or frequently bounces between site logins.
I don’t think software password managers make sense on monolithic desktop oses, which run everything in the same os image.
I use keepassxc on qubes-os, where its in its own vm, and so is everything else. The relevant vm only ever sees the password pasted into it. Unfortunately Qubes uses X11 instead of wayland, so everything in that vm can see it. Browsers for specific contexts get their own vm to minimize that attack surface.
The best I can think of is passkeys and keeping your password manager on your phone. Passkeys won’t save you if the os get compromised. Most mobile oses, including ios and android, are better about compartmentalization than monolithic desktop OSes. Graphene is good.
@donutfreak on locking between uses - reasonable idea, but if the system is already infected with a keylogger, locking doesn’t actually help. The keylogger just waits for the next master password entry and catches it at the moment of unlock. So you get the friction without the actual protection.
@winteranimal Qubes is a genuinely solid approach, VM-based process isolation does reduce the attack surface. But it comes with its own cost: entering the password becomes mentally harder, it goes through the clipboard, which KeePass can no longer reliably clear in an isolated VM. Plus you still need to back up the database in case you lose access to the working machine, and none of this removes the actual act of manually typing passwords (to even reach the database in Qubes, you need the disk password, the user password, and the database password itself - at least 3 complex, highest-stakes passwords still living in your head or on a sticky note, still getting typed by hand).
What if a hardware password manager typed the passwords for you instead - via keyboard emulation, no clipboard involved at all? And worked the same way everywhere: Windows, Linux, Qubes, phone - no software, no VM setup, no tradeoff between convenience and isolation. Plug it in, use it.
There are ways to implement alternatives to passwords or something similar to 2FA in many of these scenarios. KeePass, LUKS (either as “2FA” or an alternative to passwods), Linux login, QubesOS login, etc can support this. In any case, if you’re still accessing sensitive data on a PC of course the PC needs to be secure. As I said earlier, this goes beyond the realm of login/decryption security and into the realm of protection against malware and exploitation. In the best case scenario, an advanced workflow with air-gapped devices could offer the most protection against malware.
They’re not always the best option and some of them can have privacy footguns enabled by default, but mobile devices are generally much more secure in the sense that they tend to have the best security features and exploit mitigations compared to PCs. Of course, security keys and air-gapped devices are even better but not everyone is willing or able to use those.
One nuance: a LUKS password and a crypto wallet seed phrase can’t be protected by any alternative or 2FA layer, by design - there’s simply no slot for a second factor. So for those two specific cases, there’s no alternative at all.And even where alternatives technically exist (KeePass, Linux login) - none of them deliver the actual thing that matters: freedom from having to remember and manually type a password. You’re just swapping one password for another, or adding a step on top. The core fact - keep a secret in your head, type it by hand - never actually goes away.
I agree with you on air-gapped devices being the best-case scenario - no argument there. The real question is something else: you said yourself that not everyone is willing or able to use them. I don’t think that’s a property of the air-gapped approach itself, it’s more a consequence of existing implementations (security keys, HSMs) being built around specific protocols and requiring service-side integration. What if an air-gapped device wasn’t tied to a specific auth protocol at all, and just handled the typing itself - emulating a keyboard, working anywhere, with zero support needed from the site or OS? Then the barrier to entry disappears, but the protection stays the same.
It’s not more common. Credential leaks from servers are much more common than info stealers on end-user devices. Which is also the reason why password managers are recommended.
I am not entirely sure it answers your specific use case, but here is what I do.
My KeepassXC database remains closed and can only be opened with a Yubikey.
I set autotype patterns for my various sign-in forms. I have a shortcut to trigger autotype.
When I need to fill a sign-in form, I hit my shortcut and plug the Yubikey, which opens the database and allows me to enter the sign-in sequence (or manually copy-paste credentials).
At this point, I confess I don’t know whether the master secret is exposed to an infostealer in my RAM.
Then I close my database.
Edit: additional info, I would love if someone has some insights to teach me.
My setup is actually a bit more complicated:
I have two databases:
one that I open with the Yubikey, containing a single AutoOpen entry, which opens the second database;
the second database with all my credentials, to be open with a very complex password
When I hit the shortcut, I insert my Yubikey, with opens both databases.
I did this to be able to sync my database with my phone. On the laptop, I use the Yubikey; on the phone, I use the fingerprint.
Though it’s a bit hacky, you could put the LUKS header onto a USB. Then you have a headless volume for which you need the password (know) and the USB (have). So you can get 2FA like that, though I conceded it’s convoluted.