Lately I’ve been increasingly worried about corrupted payloads of even open source password managers. Password managers are among the world’s biggest honeypots. Maybe you trust the coders of the password manager. Maybe it’s Open Source. But do you trust all of its upstream dependencies? And all their CI build processes? And each of their developers’ security?
That’s part of why I won’t use an Electron-based password manager like BitWarden: there’s no Electron app with a minimal dependency graph. Even Electron itself could easily fall victim if someone important in the development pipeline is compromised… And besides, Electron sucks anyway.
So, one way I can mitigate against the possibility of a malicious payload being delivered on password manager update is to not put all my eggs in one basket. For example, where I can, I authenticate with a Yubikey (if only by TOTP on Yubico Authenticator). Then my password isn’t enough. But where do I store the recovery codes? Ugh: in the password manager.
I’ve been thinking on this for a while, and I haven’t really found a perfect solution that provides me a way to store secrets without also being too reliant on one party’s software. If I rely heavily on the password manager, that puts too much trust in it. If I rely more on a hardware token, that’s too risky in case of loss of theft.
What’s a security-aware nerd to do?
It isn’t pretty, but BitWarden is otherwise great.
Use KeePassXC. Only place passwords that will be needed on a device. Don’t upload to a server that you do not own.
I think if you’re using Keepass/Strongbox, and using e2e iCloud encryption, that’s good enough for most users.
Just have a backup somewhere.
No no no, not Keepass, Strongbox, or iCloud. That isn’t trustworthy.
Why?
Why is KeePassXC better than KeePass?
Strongbox, iOS, and iCloud are closed source so using them places all trust blindly with their developers. Third-party audits are impossible. Their privacy policies are all that users have to go on. After Snowden, privacy policies don’t mean much.
Strongbox is Open Source.
You can use it locally, over wifi, whatever.
I viewed their page without JS and missed their GitHub link. That’s good, but I won’t trust Apple until their OS is reproducible from source. The license is also incompatible with the Apple App store.
Really, anything distributed through the Apple App Store isn’t compatible with AGPL. For that matter, it’s not necessarily clear that GPL is compatible with the app store at all.
What do you do for backups?
3-2-1
What’s funny working in the cybersecurity space is we’ve actually adopted Bitwarden I’m out org. Now, with that said to your point not all our eggs are in one basket.
Most of our auth (if not all) relies on another mechanism for authentication. Typically some other 2FA mechanism that isn’t stored in our org Bitwarden vault. We enforce that separation with the assumption that if our vault is compromised the core aspects of the business easily accessible isn’t necessary breached.
The break glass accounts / etc that are not protected by 2FA are 99% of the time locked down to only be able to use that use from very specific subnets and or source systems. The ones that are accessible outside (say a AWS account) is always locked down with a hardware key. This isn’t fool proof either as technically in a very targeted attack you could focus on the admin/IT user and work your way through their system. To your point…it’s Electron based, but we also found not offering it and making it easy for the typical user often led to even worse practices being adhered to.
We’ve embraced Bitwarden at this point pretty heavily, but at some point we will be rolling our own instance and migrating that way. This will allow a bit more separation and control for more of our break glass based accounts.
I think for a business, there’s usually someone somewhere with the keys to the kingdom and that can be appealed. If you lose your secrets, they can be reissured.
For individuals it can be more complex. For instance, you mentioned you don’t keep all your eggs in one basket. A yubikey is a great second factor for that, but then what if it gets lost? Well, you keep your recovery codes, right? Are they stored somewhere safe from fire? Are they, for instance, in a password manager?
In simpler terms, suppose your house burns down and your devices in it. Suppose you used end-to-end encryption for your iCloud files. Could you get all that data back? And if so, how? It’s a useful thought experiment.
Current have two Yubikeys for personal use. One is a backup and remains in a fireproof safe, while the other is on my most / all of the time via my keyring. Agree the individual side is a bit more complex.
For me I took the approach of not relying that much on cloud services and rolling a lot of it myself. My data then gets backed up to a backup repository via borgbase in the EU. Usually try to follow the 3,2,1 rule for backups. Three copies of your data on two different medias with one copy offsite (ok the two different medias thing i cheat a bit and have a couple extra disks).
The enterprise side we’ve talked about implementing Yubikeys in the org, but havent gotten all the buy in on that yet.
Do you use a safe deposit box?
Sadly no, just have the fireproof safes you can find at most big box stores.
That’s the weak spot. It seems unlikely, but if there were a natural disaster or house fire, you’d lose access to your vault and your data.
In my case, that would be irreplaceable family photos, which is why I’m thinking about this more. I have an off-site backup for my data, but I’d need to be able to decrypt it.
If you’re really paranoid about this kind of stuff, you can look into using QubesOS. It uses Xen (“bare-metal” hypervisor) to isolate software from each other, and their docs is pretty good.
You could run an offline password manager from an offline VM and use Qubes’ inter-VM clipboard.
A coworker of mine uses Qubes to login to dating sites. He’s probably an interesting date.
Honestly, the computer also being compromised hadn’t occurred to me, but it could certainly happen. If you really want to expand out in that direction, you could even consider a hardware password manager.
I did not mention it with relation to a compromised computer, but wrt a compromised supply chain for the password manager.
Imagine your password manager suddenly turns malicious and tries to exfiltrate your secrets. If it is running in a VM that does not have access to the internet, its attempts to send your passwords to the bad guys are useless unless they have a VM escape exploit. I consider it a massive upgrade to your security game
That’s a good point. You wouldn’t have to trust a password manager nearly as much if you contain it in a VM.
That’s the whole point of QubesOS : you don’t have to trust any specific software if they each run in their own VM.
It’s a bit more complicated than that, since you probably want to be able to use a given file with different software (for instance, download a document from your browser, edit it with LibreOffice, and send it as an attachement with a mail client). It’s the usual security vs usability tradeoff. You never completely get rid of it, but QubesOS has a lot of neat features that make is easier to understand and decide which software you trust with which data
I put my recovery codes on paper. I’ve said elsewhere, but the threat model has changed. Heck, I even printed my password vault with paperba©k using wine once (shredded it shortly after because i didn’t have a proper storage procedure.
What if a house fire destroys the recovery codes with your devices in the same home?
It’s a fair question, but then I might revisit the question, what is the threat model? Which is higher risk? Online attack, or Fire while at home, where you are isolated from a device you’d likely also try to use to call emergency services? It is a genuine question, rate of attack on the public is probably not that substantial, but fire is also not super likely.
Though you have got me thinking, an outdoor fire safe near the front of the property… though probably only possible if you live in suburbia.
I think those are all reasonable risks. No, they aren’t likely, but you still have fire insurance, right?
An online attack targeting you as an individual consumer might be low, but they do happen, especially when there’s money (eg, banking credentials) on the table. With password managers finally becoming more mainstream, I think that’s a honeypot that criminals are unlikely to avoid. For example, consider thieves shoulder surfing your iPhone before stealing it, giving them access to Apple Keychain. In that WSJ article (see also related video without the paywall).
You can protect against the fire or lost device scenario by having your secrets in the cloud and recoverable without a physical token, but that then increases your vulnerability to theft like the WSJ mentioned.
For my lifestyle, this is even more challenging, because I don’t really (right now, anyway) have a permanent domicile.
