I fell in love with 1Password (and immediately switched from LastPass) once I discovered it can parse and save the Authenticator qr code and auto-paste it at every 2FA step.
Taking a stab at reasoning through this:
My understanding is that having a second device means that if the password was stolen, someone still needs another secret to log in successfully. In this case, if a password was stolen from the site itself, the 2fa code generator is not.
However, if the 1pass master key was stolen, then both the password and any 2fa code gets stolen as well. That puts the main vulnerability on the master key one uses for 1pass. (So looking at it that way, one should never use the master key as a password for anything else).
It does lose the advantage of having a second authentication device, though maybe not necessarily losing the protection of a second factor.
Is there something I overlooked in this? I’m no security engineer so I am not used to thinking in this way, other than maybe when I play Go.
Stolen from where ?
The vast majority of attacks which impact real people on today's web involve the data being stolen from servers in bulk.
You should assume bad guys will steal all the available credentials. Is it possible they're too dumb to also dump the table labelled "TOTP Seeds" when they get the "Hashed passwords" table from your favourite web site? Yes, but you can't rely on attackers being incredibly dumb even though many of them are.
A password manager makes TOTP moot for these scenarios as I outlined in a separate message in this thread. TOTP doesn't hurt, but if you have to pick between spending ten minutes today adding TOTP codes to accounts in your password manager or going through changing the password from "Liverpool2005" to an actual randomly generated password on a few sites you imported but didn't give fresh passwords, the latter will make much more practical difference.
The one-time password advantage still exists if you use a password manager, and I'd argue it's the main advantage. It greatly increases the effort required to successfully hijack a login flow. It prevents account takeover via password reuse / leak. It does not help if the OTP seed leaks as well but it's still a lot more secure.
Now on second factors: What is it? If a password is something you know, a second factor is something you either have or are.
The wikipedia page on MFA (https://en.wikipedia.org/wiki/Multi-factor_authentication) gives a good summary of the philosophy behind it but concretely, the separation between a phone's encrypted 2FA database and your local password manager's encrypted database is not that large. They will likely be on the same network (the 2FA device is unlikely to be airgapped); they will likely have the same owner; etc.
Unless your threat model is "people are already on my machine and have access to my RAM, or my files AND system-level keystrokes" (in which case I'd argue you're already beyond fucked), then a password manager won't be any less of a second factor than a phone authenticator. Either will be less secure than a hardware key.
Risk does greatly increase if you're using a browser extension as the threat level becomes the browser's sandbox. But security is also about convenience, otherwise you'll find people sharing a taped hardware token with its pin written on a post-it note next to it and call it compliant.
You are a user of hot new site clown-mishaps.example and Jim is a Bad Guy of some sort.
1. Credential stuffing. Jim has 10M username / email address / password combos from some "Hacker" site and he is trying all of them on clown-mishaps.example because he just figured out their rate-limiting depends on session cookies (Oops)
If you have TOTP then this doesn't work, but, if you have a password manager you should also be using unique passwords, that is after all what the password manager is for, so, you should be immune to credential stuffing anyway. This seems like a wash.
2. Live Leak. Jim discovered that the credentials backend for clown-mishaps.example uses say a noSQL system in the cloud on a non-standard port, he connects to this system and queries your credentials to log in as you.
TOTP makes no difference here, no matter how you do it, the seed stored by clown-mishaps.example is enough for Jim to make TOTP codes. If they used a password hash and if your password manager makes decently strong passwords Jim can't figure out your password but TOTP didn't help.
3. Slow Leak. Jim found the S3 bucket "clown mishaps pwd backups July 2020" with a text SQL dump of a historical database. Oops.
TOTP still makes no difference here unless you didn't enable it until after July 2020, but then that's the same if you changed your password, or only created the account later.
4. Phishing site. Unfortunately clowns-mishap.example is a phishing site. It looks just like the real thing. Jim sets it up to capture live logins, cookies and so on. You can get tools to help do this for popular login systems.
If your password manager is hooked up to tell you about phishing attempts you might get some warning, but TOTP makes no difference to that. Whether not knowing your TOTP seed hurts Jim will depend on the details of the site's security systems, but in most cases if his phishing site fools you into attempting to log in it's game over.
WebAuthn completely protects you in all four scenarios, and a password manager does at least potentially help you in all four scenarios, but TOTP isn't really adding anything on top of the password manager except in scenario #4