Comment by tedd4u
1 day ago
Strong support for the strategy of not putting your TOTP/MFA in your password manager, which has been argued on HN in the past.
1 day ago
Strong support for the strategy of not putting your TOTP/MFA in your password manager, which has been argued on HN in the past.
> Strong support for the strategy of not putting your TOTP/MFA in your password manager
Agreed, but I think using the same device to access your password manager and for dev is asking for trouble in the first place.
Password managers assumes a non-compromised device. I don't think there exist a password manager that is explicitly designed for a compromised/hostile device.
A password manager + built-in TOTP on a dedicated device is fine for most general usage. Important TOTPs can go to Yubikeys.
>Agreed, but I think using the same device to access your password manager and for dev is asking for trouble in the first place.
That seems somewhat unrealistic? There are many passwords you need to use as part of dev work.
One could perhaps put those in a different vault. Sounds like a pain to me. But nothing compared to an email and/or banking compromise.
4 replies →
That’s a good point.
Maybe a good compromise is to use 1pw for most TOTP but keep your gmail / iCloud and a few others in an iPhone only app?
Gmail is what scares me the most. It’s basically keys to the kingdom.
> Gmail
We might all do well to remind F&F to print out account recovery codes, and then put some thought into where they'll be safe.
I settled on that after trying to be extra careful with TOTP. Now my split is 95% of passwords, TOTP codes and passkeys in 1Password, 5% (really important stuff like email) in an offline KeePass DB + passkeys on Yubikeys.
But it's a hassle to have at least 2 yubikeys in case you lose one. And since you regularly sign up for new websites with OTPs, gotta keep them in sync. So always carry both with you. And if you carry both, then it's easy to lose both at the same time.
UPDATE: also gotta keep track separatelt of non-resident passkeys tied to Yubikey, because Yubikey doesn't know where it was used for non-resident. If you lose one yubikey, need to sync all passkeys to a new replacement one.
I add a note in the password manager's notes field for sites where I've added Yubikeys as the second factor. I can get the list of the sites using search, and from time to time I go through them to check if a backup key needs to be registered. I create new accounts infrequently.
Would be nice if you could get an exact clone of a yubikey, so you always have a spare in case you lose one.
Though I think there is also the option that sites can store some sort of identifier on the key, then this would not work:/
> I don't think there exist a password manager that is explicitly designed for a compromised/hostile device.
The crypto people tried this with hardware only password managers but they were too annoying. I have a halfway solution of using pass with Yubikey/GPG where each password decryption requires a touch. It does protect against the entire vault being decrypted at once and exfiltrated.
> tried this with hardware only password managers but they were too annoying
And besides that, ultimately if the computer you're using been compromised, whatever you do on that computer can be mucked about with, so while the password sits safely on the hardware, once you're logged in in the browser, the cookie is just sitting there. I guess you'd get furthest isolation with Qubes et al, but with a regular Linux installation you'd still be exposed with a hardware password manager, if the installation been compromised.
> Important TOTPs can go to Yubikeys.
Once you have a Yubikey (preferably two, so you have a backup if you damage/lose one) - you may as well make _that_ your primary MFA method, and only use TOTP for services you can't enrol your Yubikeys on.
> Agreed, but I think using the same device to access your password manager and for dev
Almost all development I do, and most others, are on our projects or projects we're at least interested in, and most likely dove into, that's why we're developing in them in the first place.
In this case, it seems like the developer wasn't actually developing anything, but playing around with image generation on his time off, for fun, and ended up pulling down a random 3rd party thing and got compromised that way. Very different from "for dev" I'd say.
Besides, didn't most developer start isolating projects from each other when the first npm worms started to appear? I know I stopped running `npm install` in the same environment I do my banking, and drastically reduced the amount of random 3rd party stuff I have, still use all the same device though. Even have a Windows install on the same computer, booo!
At the very least, a different account for your password manager at work, hopefully paid by the company, which you don't install outside of company-controlled devices.
On Linux, would something like Snap or Flatpak have protected them? It seems nuts that a random executable should have access to the password service.
Ultimately it depends on the exact mechanism here, maybe the tool/README said "Run sudo ./setup-deps" and they followed it, or something similar, not sure any sort of software isolation would have helped at that point.
Yes if the flatpak sandboxing is enabled. A flatpak can just request access to anything, the software store thing shows a bunch of scary warnings when they do this but many users probably ignore them.
You can make it so you need a YubiKey to login to 1Password the first time on a new device
So just waiting for the password won’t be enough
The hackers will literally have access to _your_ device though. If your device is already trusted, I doubt that setting will do you any good.
I think this is true in technical terms, but I have not seen a compelling description of what that looks like without it sounding like a real pain to manage.
Does anyone have a description of something manageable?
Keepass, use different db stores for passwords than for the MFA/TOTP. never store the keepass db passwords anywhere except your head. Use a different device for the totp db than the passwords.
Wonder if you could run your password manager in an isolated sandbox that couldn’t provide the secret behind the TOTP, only the current value.
> putting your TOTP/MFA in your password manager
I suppose the inverse would be starting with a device that offers TOTP/MFA, and then making your password-manager/vault somehow available on that same device. In either case, bringing them together makes it easier for an attacker to compromise both at the same time.
On reflection, I've never actually put my (personal) password vault on my phone, but that may be less of a conscious security stance than fulfilling a millennial stereotype, where certain tasks (like big purchases) are reserved for "a real computer."
Closest I've gotten is having my USB backup keychain in the same pocket, so I could get to it in an emergency, but it's inconveniently air-gapped.
As much as I like the Apple Passwords app, one of its downsides is that if I have my TOTP app on my iPhone, both passwords and TOTP live on the same device. So for many services I use Bitwarden for passwords.
For TOTP i use ente auth[0], which i can higly recommend.
i also force most apps on iOS to ask for face id (long press on app icon to set this).
[0] https://ente.com/auth/
i would also offer, do not use the same device for everything, make sure any local connectivity has firewalled [dot]finances, and [dot]tech lab from each other and else. you should probably split your network to further isolate.
use intentional spelling mistakes in your password vault, edit the password by hand. you also need to have some way of authenticating login components to be sure your running your version of login, and not a trojan login.
Separate and additional auth service based on physical ownership is always nice!
Or using a hardware authenticator.
Story states he wasn't using 2FA for his 1password account at all.
why was he even bothering then