[solarkraft]

I thought the 2FA all the big services have is so that they will deliver you your encrypted vault, rather than another layer of encryption? (I know FIDO can theoretically do that, but AFAIK it really wasn't designed for it).

The threat isn't the service having the encrypted vault anyway; we kind of trust the encryption to be decent (though of course you can't know what technological threats are looming).

The real threat is that you're putting your password for decryption into a proprietary blob with an internet connection and auto-updates enabled. It might be sending your password random places now or maybe at some later point.

Note that even a source-available password manager doesn't really solve this issue if it's not self compiled - and most of the time you'd probably want automatic security updates enabled on something security critical. But they can put anything they want to or are pressured into putting in there.

[schmichael]

> I thought the 2FA all the big services have is so that they will deliver you your encrypted vault, rather than another layer of encryption?

Correct, 2FA is protection in addition to your password manager. So if someone gets your unsealed vault they cannot log into any services without also compromising your second factor. 2FA is not for further cryptographic hardening of the vault itself.

> The real threat is that you're putting your password for decryption into a proprietary blob with an internet connection and auto-updates enabled. It might be sending your password random places now or maybe at some later point.

If you use Chrome and Safari your passwords are going through a proprietary blob with an internet connection and auto-updates enabled. If you use extensions for your browser they likely can steal all of your passwords.

Nothing can protect you if you don't trust any of the code you're putting your secrets into, although 2FA with some USB devices cover a mind boggling range of threats. A keylogger and screen capture combined wouldn't be sufficient to bypass them.

> Note that even a source-available password manager doesn't really solve this issue if it's not self compiled

Are you compiling your browser from source after verifying every line of code it contains? If so what makes you think you can trust your compiler?

You have to trust something. Choose your threat model. Choose your risks. Live your life.

[jrm4]

Actually -- a "web of trust" idea for the browsers is quite sufficient.

Google et al... have already proven that they are at least decent at security and that they care about things owing to their success in the market. They've proven that they've handled this reasonably well and following their lead on how to do security in software is probably pretty good. They have both experience and skin in the game, lots of it, in the form of lots of money et al.

NOW, these password companies? NOPE. They simply don't have the right incentives in place to be trustable. (or more specifically, that they're going to be much better at securing my stuff than I will) They're too young and don't have sufficient "punishment" at the ready for me to be able to trust them much. They don't do indemnification, and liability for them isn't going to be great. I can't presume the same level of skill or care because the infrastructure/incentives aren't as presumably solid.

(Put differently, the Lifelock guy was a hero, he was at least willing to put something real on the line.)

[g_p]

Yes, 2FA/MFA is almost always just an access control measure over who can retrieve the (in this case encrypted) data from the server.

TOTP is based on a shared secret that client and server both know (so inherently a compromised server can just skip it). For webauthn and similar, the token will sign a specific challenge, incorporating the site name and a counter value etc. The server stores the public key, but the check can be disabled.

The real risk is the auto updating client and the integrity and supply chain of the code it runs - unless you actually audit the client code, there's limited value in compiling it yourself. If the attacker can ship you a compromised signed binary, assuming the company is competent in their setup, they've compromised a development environment, code review environment, code signing environment, perhaps a CI/CD and testing environment, and then the release distribution environment. To get you to compile and install their dodgy source only requires a compromise of their development environment, as very few organisations will slow down their routine development cycle enough to add significant barriers to this one layer being compromised (as it has to be done for every commit checked in, every dependency changed, etc.)